I’ve been casually following the chatter on the hy-bi list about Web Sockets for the past few months. The specification has reached the final draft stages, but the list is still  a bee hive of rhetorical debates about several of the protocol’s features. The common thread between these debates is the complexity of the protocol which  is starting to look more like a monolithic group of sub-protocols.

The “amateur programmer” clause has been struck out from the draft. It is no longer an over-arching requirement that the specification be easy to implement by novice programmers. This means that the programmer’s api will also end up being quite complex so I expect most web developers will end up using jquery-like abstraction libraries rather than writing socket code directly. All the better, because I don’t think many web developers want or know how to do socket programming anyway.

Security continues to be an ongoing concern. It has been suggested that the protocol should be able to take advantage of TLS/SSL. However this can add communication overhead and reduce the real-timiness of the applications. The trade-off between security and efficiency is always a tricky one. Financial and mmorpg applications need a high data update rate all the while without being vulnerable toman-in-the-middle attacks. It’s not clear where the line will be drawn between performance and security in the web socket protocol.

There does not seem to be a clear consensus on connection management. There are two schools of thought here, one of which argues that the protocol should support it natively while the other argues that it should be left to the application. Once again, this is a debate about how much complexity is too much complexity.

Lastly, two draft editors have resigned or have been too busy to contribute. If you’re interested in getting involved, you can start following the discussion here.