I really like the idea behind the HTML5 Websocket API – namely that a datagram model should be used for web application communication rather than a request/response paradigm (this is also the idea behind cometd). But unfortunately, the proposed protocol to carry websocket traffic is neither a good protocol nor is it well specified.
After failing in an attempt to get the WebSocket protocol improved, I decided to try to define a better solution. I had intended to work privately on this for a while, but the twittersphere has pointed out an early draft, so I’ve put the work-in-progress on http://bwtp.wikidot.com and I invite review, feedback and collaborators.
So what’s so bad about the Websocket protocol proposal? The main things I dislike are that the document is impenetrable, the protocol inflexible and it is entirely different from other IETF application protocols for no good reason. But rather than throw (more)mud, I’d rather sing the praises of the approach that I have taken:
- The BTWP protocol is very much an IETF style application protocol. In fact it is just RFC2616 with anything non bidirectional ripped out. It is not trying to be a revolution in web protocols, but simply to solve the problems at hand, without discarding decades of protocol experience.
- The protocol document is written very much in IETF style. In fact it is just RFC2616 with anything non bidirectional ripped out. BNF is used to specify the protocol and unlike the WebSocket proposal there are no binary blobs or algorithmic specifications.
- The principal of “be strict in what you generate and forgiving in what your parse” is adhered to.
- Because of it’s similarity to HTTP, it is intended that existing HTTP clients, servers and intermediaries will be able to be minimally updated to support this protocol. This will not require entirely new protocol libraries to be developed.
- Existing development and analysis tools will also be able to be easily updated, plus the protocol is mostly human readable.
- It supports full mime encapsulated payloads, so non text payload and/or compressed payloads can be sent without the need for clent and server to make assumptions with regards to content.
- It has a default meta data mechanism, so that it can have detail per message meta data, but not at the expense of the redundent inforamation sent in normal HTTP.
- The minimal overhead per message is 11 bytes, which is a little more than the websocket proposal, but is hardly significant.
- There is no formal channel mechanism like BEEP has, but each message may be to/from a different URI if need be. This makes multiplexing easy to support.
- There is no formal segmentation mechanism, but Content-Ranges are supported so that large content can be sent in smaller bits if desired.
- The protocol recognizes that intermediaries (proxies) may wish to be an active party on a bi direction connection. For example, this proposal allows an intermediary to initiate and orderly lossless close of the connection. I’m sure innovative proxy applications will be developed over time, just as they have been for HTTP.
- BWTP well supports the current HTML WebSocket API but is also flexible and extensible so that non browser clients may use it and future APIs will not need protocol changes.
If you are interested, I encourage you to join the IETF Hybi mailing list and to join the discussion ragarding the bidirectional web.