The WebSocket protocol, design by committee and requirements tracing
I’ve been working with the WebSocket protocol recently, updating the code that implements the protocol in The Server Framework to the latest version of the draft standard (the HyBi 09 version). Whilst this looks like it’s almost a real standard, there are still lots of potentially open issues as can be seen from the HyBi discussion mailing list.
It’s quite clear from some of the less cohesive parts of the draft spec (and more so from the mailing list) that the protocol is very much a design by committee effort. This is both good and bad: It’s good that the protocol includes support for a wide range of use cases and, well, it’s bad that the protocol is more complex because it includes support for a wide range of use cases…
It would be fascinating (and time consuming) to read through the discussion lists from the start and track the reasons behind the various changes and evolutionary steps that the protocol has gone through. Unfortunately, at present some of the elements of the protocol require you to do that if you want to understand why they exist. Without reading all of the discussion list there’s a lack of traceability from the various elements of the protocol to the various use case requirements that caused them to be included. Given the evolution of the protocol it’s likely that some areas of the protocol have become detached from the original requirements (as other areas have been modified and now no longer support the original requirements, for example, the idea that WebSockets is a message based protocol is undermined by defining a message in terms of an infinite number of fragments without any form of message length indication).
All of this means that implementing the protocol from the current RFC is harder than it needs to be and often the wording of the RFC itself will lead you towards designs that don’t work well with the actual protocol. Ideally all of these loose ends will get cleaned up before the standard is ratified but the protocol has been in draft form for a long time and I’m sure some would prefer it to be ratified as is rather than go through yet another round of changes…
I’ve been accumulating several rants about the protocol and I’ll be presenting them as stand alone blog entries (mainly because they’ve each grown too large to be joined together in one entry). Often the solution to my frustrations would simply be a modification of the descriptive portions of the RFC text to give a little more explanation as to the thoughts behind the decisions.
