Thanks to a premature Ajaxian mention there's some real wind in the sails of Cometd, a primordial little Comet server and protocol project that I'm lucky enough to be working on. The goal of the project is to produce a content-level protocol for publish/subscribe event notification down to browsers. We need a name for the protocol (as distinct from the code), so if you have ideas, we're all ears.
Unlike some predecessors, however, a couple of neat features should help to make Cometd clients and servers resilient in the face of browser and network stupidity. The first of these features is "transport negotiation". At the core of it, there's a realization that browsers very rarely all do the same thing the same way...especially when you're out pushing on the lightly tested bits like we are. We get around this by having the client and server advertise what they want to speak over, and if they can come to some agreement, the conversation starts. Since the protocol is so simple, this generally means that servers can implement almost every type of transport with exactly the same code. The Twisted Python server does exactly this. This is very interesting because it allows us to implement most of the known Comet techniques with very little overhead. In the last 2 days I've implemented 3 different styles (forever-frame, multi-part-mime, and long-polling) which cover most of the modern browsers with at least one transport method. Each method exhibits different bugs, browser compatibility headaches, and performance characteristics, but being able to swap out one technique cheaply for another is going to let us experiment that much faster with how best to implement Comet systems.
If there's a secret sauce to Cometd it's that both of the initial implementations are being based on async network responder frameworks. On the Perl side, Perlbal is doing the heavy lifting while the Python variant relies on Twisted. Obviously there's a lot more to these things than picking a good library, but it sure helps. There's even been some discussion of how Java, PHP, and Erlang implementations could be made to scale using similar techniques.
Hopefully we'll get a new name for the protocol bits of Cometd soon (and a draft of the spec shortly thereafter) and once the Python server does topic and client pruning I'll try to get some demos hooked up. After all, it's the sexy collaboration that sells this stuff.
Update: seems I forgot to mention that in addition to the mailing list, the Cometd project also has one of them newfangled "blog" thingers.