[whatwg] BWTP for WebSocket transfer protocol

Maciej Stachowiak wrote:
> 
> On Aug 7, 2009, at 12:25 AM, Greg Wilkins wrote:
> 
>>
>> 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.
> 
> From my review of the spec so far, it doesn't look like we'd be able to
> reuse much of our existing HTTP client implementation, at least not
> easily. The general header field parsing may be the same, but that code
> is trivial. The complex parts are the handling of specific headers,
> caching and connection management, and in most http libraries that code
> is not structured in a way that makes it easy to pick and choose. My
> tentative estimation is that the implementation effort for BWTP would be
> considerably higher. That's not to say it's a showstopper, it just means
> there is a tradeoff between additional functionality and implementation
> complexity.

Maceij,

That's valuable feedback.  My experience is mostly the server side
and I think when it comes to connection handling the server has an
easier time of it than the client - so I can see that BWTP would
have more of an impact on the client.

Remember, at this stage BWTP is a thought experiment, so it is
definitely easy to adapt to new ideas or drop features that are
too complex for the benefit they give.

So are there any changes or omissions that you can suggest that
would make a client implementation easier?

For example, I proposed the default header mechanism to address
concerns Ian expressed about per message byte count.    However,
this is not something that HTTP does (and we get by with hundreds
of bytes per request), so perhaps we could leave out the default
Header mechanism at the price of more bytes per message?

Also there is the possibility of making features like multiplexing
optional and negotiated.   This would allow  simple non-multiplexing
implementations, but might cause additional complexity in negotiation.
That really comes down to how important people think multiplexing is.
I think that it is moderately important because I can imagine pages
with 10s of individual widgets, each opening a websocket, so my
server will be looking at 10x the number of connections per user.
If users open multiple windows, then it's 20x!   On the server,
connections are pretty cheap, but not that cheap.


cheers

Received on Friday, 7 August 2009 17:00:50 UTC