Support newer (web)socket libs

[shimaore]

Suggested on the list (by klrumpf), see http://stackoverflow.com/questions/16392260/which-websocket-library-to-use-with-node-js, ws and sockjs as primary targets.

Probably replace/complement the disable-io option with an io option that could be socket.io (default for backward compatibility), ws, sockjs, ..

I suspect this requires changes on both the server and the client code.

[shimaore]

We now support the io option, but this needs tests to confirm the APIs are compatible with the way we use socket.io. (The session-sharing code comes to mind as a place where we depend on private APIs.)

[shimaore]

Hmmm... The APIs are different ( Socket.IO says emit, ws says send, sockjs says write 😒 ).
On the client side, we're dealing with socket.io-client, native websocket, and sockjs-client.

[shimaore]

I've looked at sockjs and the API only supports a single Unicode string as data. This would require a lot of client-side vs server-side conventions (starting with things like "content of Unicode string is actually JSON") to support basic things like session-sharing between Express and SockJS.

ws looks more promising and would allow us to support native websocket; it doesn't have native support for multi-server deployments though (like Socket.io does using a Redis backend, for example).

[shimaore]

ws actually supports data transport, but doesn't implement the message-vs-data concept that is present in Socket.io either. Would need some conventions client-side to implement this as well.

EDIT: in other words both sockjs and ws would require a higher-level API with a message router.