One of the negative phrases about Comet I see most often is “Oh, HTTP push. We did that ten years ago. That’s nothing new, so why give it a fancy name?” Statements of this type are very good at exposing their authors’ ignorance. No one has ever suggested that Comet is a brand new technology, because it isn’t. It, like many other technologies, is based on past forays into similar territory. Making such a statement would be akin to saying, “HTML5? Oh please, I was writing HTML in the early nineties.” Besides the fact that HTML was the first hyperlink markup language, it’s ludicrous to suggest that the HTML5 specification adds nothing new to the world past what we had fifteen years ago. As Jacob Rus discussed, HTML5 has the potential to be quite significant for Comet. It’s even ridiculous to suggest that HTML was somehow revolutionary—it’s just a descendant of SGML.
The point of Comet is to collect a whole host of disparate push methods and unify them as a single, useful technology. Iframe streaming, a technique employed for at least a decade now, is actually not very useful on its own. Without combining it with the htmlfile tricks for Internet Explorer, and the loading bar tricks for Firefox, iframe streaming is an eyesore that belongs nowhere near a production site. And without polling as compatible fallback, iframe streaming would be brittle in the face of browser connection limits. Let me be again clear here that Comet isn’t a new single technique. Rather, it’s a combination of existing push technologies with further research into new methods that together provides a robust framework for pushing data to all clients on modern networks.
Once we have a formal standard for push communication, and some well-published best practices for falling back on different methods for the appropriate situations, we’ll then have something useful that didn’t exist ten years ago. And in fact, the progress we have made so far is most of the battle: it’s useful, and it didn’t exist ten years ago.