[whatwg] BWTP for WebSocket transfer protocol

[Jonas Sicking]

On Fri, Aug 7, 2009 at 12:25 AM, Greg Wilkins<gregw at mortbay.com> wrote:
> 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.

cc'ing Wellington who has written a websocket implementation for Firefox.

Would be great to get his feedback for what savings could be done if
we were to use BWTP as transport protocol compared to using websocket.

My impression is like Maciejs, that we wouldn't be able to reuse much
of our current HTTP infrastructure in order to implement BWTP. At
first glance only the header-parsing code would carry over directly,
but that's not many lines of code and so doesn't seem like a big win.

>> 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.

I agree that these are very interesting features. Especially
connection multiplexing is something that I think is a good idea, for
the reasons you've mentioned elsewhere in this thread (multiple
widgets on the same page). But even compression is nice if it was
possible.

My gut feeling on BWTP vs. websocket is that BWTP carries some
unneccesary complexity/overhead by allowing arbitrary headers in each
frame, whereas websocket is unnecessarily low level.

I don't think BWTP gains a lot by using HTTP-like syntax, as I don't
think that in reality a lot of existing HTTP code can be reused.

/ Jonas