Joe Armstrong in a recent blog post (which made it to reddit) announces the coronation of HTML 5 websockets now that Google has added them to Chrome. He’s also pleased to relegate Comet, long polling and its friends to the grave. This confuses comet with the techniques used to achieve it.
Back when Alex Russell coined the term Comet, he talked in terms of what it was possible for browsers of the time to do – holding open HTTP connections, but it’s obvious from his post that he was thinking of any of a family of techniques for pushing data to the web browser.
Here at Caplin, part of our Xaqua platform is a world leading comet server called Liberator. According to Joe, that part of our offering is about to be outdone by websockets. In actual fact, we’ve been waiting and hoping for websockets for a long time, not because they will replace comet, but because they will make the comet experience better. When we first played with a websocket implementation (Kaazing’s websocket server), we were excited about using them but since there had been no indication back then that any browser was going to support them natively, we held off.
Our streaming comet server, Liberator accepts connections from Flash, .Net, Java clients and native clients, but it can also use a plethora of different techniques to allow web browsers to connect, from applets with direct socket connections (hardly used at all now), to long polling, multipart-replace techniques, or simple long running XHRs or forever frames (many of these techniques are described here). There are others too – server sent events, etc. Each of these techniques has different benefits, different firewall traversal characteristics and many of them only work in a subset of the browsers we support. As with any well architected Comet server, different techniques can be plugged in, new ones can be created easily, and the best one for any situation can be selected automatically for establishing the connection.
Websockets will not change any of this. It will provide yet another substrate option for our Comet connection to run over, one that will have some benefits over many of the other techniques, and once we have implemented it, it will be automatically used where appropriate. The fact that it’s so far only supported by development versions of Chrome will mean that that will be less than 10% of the time, but we can hope that more browsers will follow suit.
Nor is providing a connection the full extent of any Comet server worth its salt. Liberator provides robust failover when the connection goes down, session management, and a full pub/sub engine and javascript API.
The key to Comet is that the normal interaction between browser and server is turned on its head; the browser gets told about events as and when they occur, rather than having to specifically ask (and this is a vital ingredient for the real time web). Comet makes no demands that we use a particular method to achieve this, and we have a huge armoury that we will continue expanding as browsers advance.
Far from heralding the death of Comet, websockets will make Comet faster, easier and simpler.