- From: Greg Wilkins <gregw@mortbay.com>
- Date: Sat, 08 Aug 2009 10:00:50 +1000
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