2 errors show up, same like when using binaryjs or ws, but with those 2 libs sockets get disconnected immediately after connection, with socket.io i get 2 warnings that 2 modules are not ELF executable for MIPS but i've read socket.io has a bunch of fallbacks so i guess that's the reason why it works. I can even send and read binary data.
But the biggest problem is that socket.io takes up to 4.1MB
@Igor-Neuhold Ah, i see. Socket.io is probably falling back to long-polling to accomplish the same tasks. Can you try to removing the binary files (that's not ELF executable for MIPS) to see if that reduces the module size by any significant amount?
around 100kb less, not enough. I would need to figure out exactly to what socket.io falls back to and remove everything else so it has a reasonable size.
@Igor-Neuhold Looking at the dependency tree of
socket.io, it seems to be dependent on
ws. How big was ws when you were using it? Also when i look at the dependencies of
ws, it's dependent on
ultron, both are 100% native node applications, so i'm not quite sure which package is dependent on the
utf-8-validatemodule that was giving the error.
just ws are ~800kb
bufferutil and utf-8-validate throws as not ELF exec...
and ws disconnects user after it receives connected event, i'm guessing that socket.io fallsback to something else?
@Igor-Neuhold Yeah, i think it should be the
socket.iothat's falling back to long polling. It seems like you will need to change some code to tell
socket.ioto start directly with long polling instead of trying
wsfirst. This way you will be able to remove
wsentirely and save 800kb of space.
it would be better to avoid socket.io and use ws compiled for MIPS, i just have no idea how to do that. Just saying if we had working ws and have an option to avoid socket.io we would save 3.2MB
@Igor-Neuhold Can you isolate the source code for
you mean in ws?
I'm not sure that's the way to go. Can't you just compile ws for MIPS or something?
as for storage I guess 4mb ain't so bad with some external data device
wsis compiled by
npm, but in order to cross-compile them for the Omega we will need to get the source code and use the cross-compile toolchain to compile them (because we don't have
npm-gypon the Omega).
maybe this can help: http://fibasile.github.io/new-node-modules.html
@Igor-Neuhold Thanks for sharing! I will test them out
Sergiy Kyrylkov last edited by
I'm looking forward to seeing
wsworking with Node.js on Onion
@Sergiy-Kyrylkov Do the packages listed here work? http://fibasile.github.io/new-node-modules.html
Sergiy Kyrylkov last edited by Sergiy Kyrylkov
@Boken-Lin I don't know. We cancelled our Onion orders until Node.js is confirmed to work with the libraries we need (Mongoose, ws). Also Node.js 0.10 has a regression which breaks our code on Intel Edison, so we cannot use anything less then 0.12
Hi @Sergiy-Kyrylkov, these are all functions we are in the process of working on. As soon as we have them ready, we will let you know. Also, are you thinking about running MongoDB on the Omega itself? Or are you going to be using Mongoose to access MongoDB on a server?
Sergiy Kyrylkov last edited by
@Boken-Lin No, we need just the Mongoose and ws. These two libraries have native components.
@Sergiy-Kyrylkov I see. Just running mongoose shouldn't be an issue. We just need to get them to cross-compile properly on the Omega. Please stay tuned for that!