[whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

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