There's a bit of buzz going around about the "real-time web" lately. The real-time web is about information delivered to the user as soon as it is available. Real-time notifications are exciting because it allows web pages to be more dynamic and seem more alive. These techniques also allow developers to mimic desktop applications, with their immediate user feedback, on the web.
With all the talk about "real-time" it's important to take a step back and evaluate the techniques we use to accomplish these browser feats.
1) Ajax (Wikipedia article)
Ajax is the technique where a user action (via a web browser) is able to update information or retrieve additional information from the web server. I won't get into too much detail because Ajax really is everywhere these days. Favorite a tweet, digg a story, move around in Google maps, post a comment on Facebook... these actions are all performed via Ajax. You, the web user, take an action in the browser and the server is notified of what you did - no web page refresh required.
2) Comet (Wikipedia article)
Comet is the lesser known of the real-time techniques and can be thought of as the reverse of Ajax (well, actually Comet often uses Ajax, which I'll explain later, but bear with me for now). An event happens that is known to the server and the server notifies the browser, updating the web page that the user is viewing. Again, no page refresh required.
The important difference between Ajax and Comet is where the action originates. With Ajax, the action is taken by the user and with Comet, it's an action from the server. Currently Comet is a popular technique for browser-based chat applications since it allows the server to receive a message from one user and display that message to another user. Some web applications that currently use Comet are Google's GTalk, Meebo's chat, and Facebook chat.
From a technical perspective, Ajax and Comet differ in the expected length of the request. Ajax uses a quick request-response to update or get new information from a server, while Comet typically opens a longer connection to get information as it is available from the server.
So how does Comet actually work?
There are several ways to implement Comet but the most common is called "long-polling". Long-polling means that the browser opens an XMLHttpRequest to the server but instead of expecting a quick response (like Ajax does) the connection just waits. If the connection gets a response from the server, it returns that to the browser right away. Otherwise after a bit of time the connection dies and the browser sends another request and waits again.
How is long-polling different from just periodically checking with Ajax?
Some web applications, such as 37signal's Campfire chat application, use periodic Ajax (quick) requests to check if there's a new action from the server. The problem with this kind of short-polling is that it's difficult to tune to get the best results. For example, if you check for new stuff on the server every 5 seconds, what happens if a new action appears right after the response returns? Well, your user waits another 5 seconds to see that action. That's okay, but not ideal. Also, a lot of Ajax requests will be hitting your server when there is no data available and may waste more requests than having fewer, longer connections.
What's the future of Comet?
The heart of the internet is communication. The next generation of web applications will not only need to be responsive to one user, but also facilitate speedy communication between many users. The quicker we can chat, message, poke, tweet as well as see and respond to these actions, the better!
For more information on Comet, the Comet Daily blog is a great resource. The most popular library for Comet right now is Orbited. We use Orbited plus Twisted IRC for Leafy Chat, our simple web-based IRC client.