Right now we use long-polling for asynchronous response. We should consider streaming the messages back using websockets.
Downside: dev tools don't capture websocket messages, no notice when the socket stops working due to say, cellphone switching access points.
IMO web-sockets cannot act reliably without a fallback to HTTP requests. A solution would have to ensure liveness of transfer, either by distinguishing and renewing closed connections client-side, or by another means.
A possible design strategy is to lift poll requests to socket commands, so that code is reused and there is conformity across protocols.
metaweta says:
IMO web-sockets cannot act reliably without a fallback to HTTP requests. A solution would have to ensure liveness of transfer, either by distinguishing and renewing closed connections client-side, or by another means.
A possible design strategy is to lift poll requests to socket commands, so that code is reused and there is conformity across protocols.
iaproxy's Mongrel2 server supports web sockets.