If you are active in Javascript development you might already heard about Comet, if you aren’t you maybe haven’t.
But you might have heard about AJAX which enabled programmers to add interactive elements on webpages without reloading them (e.g. replacing content with form elements and saving it back without a reload).
Comet now is a step further in that it allows even more dynamic webpages. While AJAX always relies on user input to start an action (e.g. you click a button or click on the Title field on a flickr photo) and thus is a client-initiated technology, Comet goes the other way round. With Comet the server can initiate an action based on some event on the server. Usually this is done by polling, e.g. the client regularly asking the client if something new has happened. With Comet thus you save this network traffic (imagine the server side getting a plethora of polls every minute if you have a lot of clients connected) and only send updates once there really has happened something.
A good example of a Comet application is maybe a chat box on a web page. This box should only be updated if somebody else posted something. So it’s not an event coming from your client but from another person’s client, initiating a server action which then results in data pushed from the server to you.
How does Comet work?
Comet actually is a hack. There is (yet) no direct support in browser but the hope is that this will change in the future. To make Comet work you also have to work around several browser problems. Thus not a good situation to be in but nevertheless this is how new technologies start.
Comet can be implemented today by several methods (taken from this great post by Jacob Rus about how Comet works today. Look there for the details):
- “Forever-frame” iframe streaming: In this case you add a (hidden) iframe to a page and you set the source to the Comet server which send a neverending HTML stream of script-Tags with callback functions.
- htmlfile ActiveX object: Usable for Internet Explorer only and discovered by the GMail team.
- XHR multipart: This is a relict from the push-technology once endorsed by Netscape, mostly used by Webcams. This enables complete HTML page replacements. If these pages contain Javascript code it gets executed and thus can trigger client-side actions. Works only in Gecko based browsers.
- XHR streaming: This is similar to the above but for Safari browsers. In this case a stream of data in a custom format is sent to the client. When new data arrives a callback is called which can retrieve more data about the event from the payload.
- XHR long-polling: This is different from streaming in that the server opens the connection and keeps it open until actually an event occurs. If this happens, it sends the data, then closes and a new connection is opened automatically. This works in all browsers.
- Script tag long polling („CometP“): This is good for cross-domain Comet and works by dynamically creating a script tag pointing to the right server. This is similar to the above long-polling.
Of course you can also utilize Flash and other plugins but this always means you need to have them installed and they are not blocked in any way.
Now the cool thing is that at the Snow Sprint last year and this year people have been working on making Comet possible with Plone. They use Plone’s AJAX framework KSS for it and use twisted as the actual server handling the Comet connections (because of the normal Zope setup it alone wouldn’t scale) and eventually talking to the Plone server.
Jean-Nicolas Bes and Ramon Bartl have been working on it this year and here is their presentation:
They also demoed a little application which uses a Comet based progress bar. The code is available as buildout which has the advantage that it installs all the necessary components automatically. You can find it here.
If you are interested in Comet in general, I suggest you read Comet Daily.
Technorati Tags: comet, plone, development, ajax, kss, javascript