> I discourage against removing the framing, even for persistent-connection > transports. > > The framing is useful if you want to alter the closeTimeout of websocket and > buffer between disconnections. > With the current socket.io, it's fairly trivial to save the session id in > a cookie or local storage, set the closeTimeout to something like 10 > seconds, and then you can buffer messages for user between browser > refreshes. Its also useful to buffer if the connection is spotty. I think it > provides great flexibility at a very small (or inexistent) price. >
Even in the case where you reconnect and expect to receive buffered messages, there is no need for additional framing for websocket connections because websocket already provides the framing. My goal is to provide semantics that are equivalent to that provided by a native websocket for the case of string messages. I'd like to also be able to add support for the binary messages, opcodes and fragments that are in the draft websocket spec, but I may need to wait for the support to be added to chrome and company. I'd like to avoid forking the socket.io.js code. Would you consider accepting a patch at some point that splits the functionality into a core WebSockets encapsulation/emulation layer and a Socket.IO enhanced functionality layer? The enhanced layer would signal to the server that it's in used via the Sec-WebSocket-Protocol value. Do you have a socket.io email list/group? I'd like to move this discussion out of wave-protocol in order to avoid confusing the socket.io work with wave-procotol work. -Tad -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
