Update

My opinion, indicated in the comments below, is now:

Comet is an umbrella term for all the old HTTP-based hacks and is a phrase we want to get rid of. WebSockets are where we want to be; browsers and beyond.

Below is the old post covering my original opinion:

"WebSockets or Comet"

I’ve been thinking about writing about this frequently used statement for a while, and I’ve seen a few comments and discussions previously about this e.g. from Martin Tyler of Caplin Systems and Peter Lubbers of Kaazing in a post on InfoQ).

Martin's point of view is:

One thing I don't understand is your stance on Comet. You seem to want to distance Kaazing from Comet, despite the fact that your WebSocket emulation is surely Comet. More than this though, WebSocket itself is also Comet since Comet is just a paradigm, not a any specific transport mechanism.

Peter's opinion is:

Comet is a programming model that allows a web server to push data to a browser. This is often achieved through a long-held HTTP request, but there really is no standard or specification for Comet; it is just an umbrella term for all the different ways that can be used to achieve this.

WebSocket, on the other hand, is a well-defined API and protocol that allows for full-duplex, bidirectional communication (not just server push).

Can you really say WebSockets is an alternative to Comet when Comet servers use WebSockets?

My current thinking is the same as Martin's (I did used to work with Martin). It is that:

Comet is a paradigm, not only for server push but also for bi-directional communication.

The need to do this with a web browser resulted in WebSockets – something which natively supported this in a way that HTTP did not. So, we have Comet to thank for WebSockets.

The Wikipedia Comet entry states:

Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction.

Alex Russell’s original Comet blog post states:

Fundamentally, they all use long-lived HTTP connections to reduce the latency with which messages are passed to the server.

The architecture relies on a view of data which is event driven on both sides of the HTTP connection.

All very HTTP related. But the second quote interestingly says “event driven on both sides”. This bi-directional communication, backed up by the diagram from the web post (see below), seems to have been lost in the wikipedia entry.

</p>

What I’m suggesting is that Comet is a paradigm for realtime bi-directional communication between a server and a client. Initially it used long-lived HTTP connections in addition to a second short-lived connection for command requests (e.g. subscribe) because it was the only solution. Comet servers now use WebSockets because they are now available, are better than the HTTP-based alternatives and help Comet (the paradigm) be achieved and finally truly realised in a standardised way.

I’m suggesting that HTTP Long-Polling or HTTP-Streaming (all using XMLHttpRequest, Script tag polling, IFRAMES, ActiveX objects) and WebSockets are transfer technologies (Martin used the term "transfer mechanism") that make the Comet paradigm possible.

I’m suggesting that saying “Comet or WebSockets” is an invalid statement and that the Wikipedia article is incorrect and that this diagram better reflects the relationship between WebSockets and Comet:

</p>

I’m prepared to be wrong by being convinced otherwise. But I don't think I am or will. Interested in hearing your opinions.

Note: I originally posted the core text to this as a comment on a blog post "Websockets or Comet or Both? What’s supported in the Java EE land"