- From: Greg Wilkins <gregw@mortbay.com>
- Date: Fri, 07 Aug 2009 17:25:51 +1000
Maciej Stachowiak wrote: > This proposal looks a bit more complicated than the WS protocol, so it > may take a bit to digest. Maciej, BWTP is indeed more complex that the base websocket protocol I think this is one of the key differences between the approach taken for the websocket protocol, which I think emphasises simplicity of implementation starting from scratch. But if your starting point is a working HTTP client or server, then the work needed to implement BWTP should not be too significant, as the additional complexities (Header fields and mime encoded content) are handle almost identically to HTTP. > For what it's worth, we are not absolutely wedded to the details of > either the API or the protocol, but we feel pretty strongly > about delivering the basic functionality. I think everybody is keen on the basic functionality. But I think it is the non-basic reality that will ultimately drive the design of at least the protocol (if not the API). For example, when there are multiple WebSocket using components in the same frame/tab/browser - should they share TCP/IP connections to a host or should they multiplex. I see this as a trade off between additional complexity in the protocol for multiplexing vs consuming extra network/server resources for potentially many connections. Another example is compression. Currently websocket protocol supports only utf-8 or undefined binary framing. Over the life of HTTP, there was no compression, then there was compress and now gzip is widely supported. It could be expected that new compression algorithms will be developed over the life span of websocket and it will be important to be able to support them without the need to update the javascript that calls the websocket API. cheers
Received on Friday, 7 August 2009 00:25:51 UTC