3 ms·
It wasn't really clear to me what the advantages of this is over a ZMQ+Socket.io based system. The aim is a fully-baked SAAS I suppose, but it seems we already
by rll 14y ago
It wasn't really clear to me what the advantages of this is over a ZMQ+Socket.io based system. The aim is a fully-baked SAAS I suppose, but it seems we already have all the pieces to roll our own without too much effort.
- dshankar 14y agoZMQ is for server-server on the backend. Socket.io would be client-server for the frontend. But the pieces in the middle would have to translate between ZMQ semantics and Socket.io semantics and it's all ugly. There is no way for a ZMQ endpoint to directly address a Socket.io client, and always have to go through this complex intermediary component. As I point out in the video, this is the strategy today. Hook up a bunch of different pieces together. Bridge is meant to be a solution that provides the same semantics for server-server and server-client communication. Thanks -Darshan
- rll 14y agoWell, there is a zmq Javascript flash-binding that gives you ZeroMQ semantics all the way to the client: http://www.zeromq.org/bindings:javascript http://www.zeromq.org/bindings:javascript Semantically it is clean, but the flash part is a bit ugly.