Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Cometd: The Long Tail of Bad Puns


interesting to see this move along, i read your slides at cometd.com. looking at the problem space you want to address with this proposal (presuming your suggested problem domains are realistic), i am wondering why there is such a pressing need to wedge this into the web stack when it appears that architectures such as xmpp appear to solve the problem in a more graceful manner, particularly with regards to the carrier protocol, for which i continue to believe http is poorly suited to solve the problems you appear to be tackling, particularly for sites that must manage high rates of traffic.

a common response to these points i hear is that everything must reside in the browser, that new clients are to be discouraged...but this is old news, IM clients and now voip clients are nearly ubiquitous, there doesn't seem to be great resistance to one more piece of software.

in any case i will be following the progress of this, seems interesting.

by grumpY! at
hey grumpY!,

It's funny, I always want to say "hey grumpY!!" to express genuine excitement at having someone smart and thoughtful commenting on my blog, but the double exclamation marks just feels weird. But I digress.

We've been having some discussions about how much of XMPP we can "borrow", potentially with an eye toward peering with an XMPP server to route messages. Our designs so far have been JSON-centric since it's so much easier to work with and since it can be directly embedded in the output stream for a lot of the output scenarios we care about. But I think we're amenable to everything up-to-and-including XMPP-in-JSON.

HTTP might be a bad solution to these problems, but XMPP isn't something that's chunkwise digestible by the browsers we have today (at least not on anything but IE) and I'm not willing to accept that browsers aren't an appropriate endpoint just yet. Users might not be resistant to another piece of software, but do you really want something else running on your desktop? Hell, I run Adium for IM specifically because it reduces the number of these apps I need to run. I kinda think this is like "convergence devices" in that people want the same capabilities in one place as opposed to being spread out, but not enough to want sucky versions of it. Anyway, Comet and cometd aren't strictly about IM. It's the obvious first application, but I don't think it's the whole story. It sure isn't the only thing we used it for at Jot and I'm not sure that we're using it for chat in any capacity at SitePen.

If you accept the premise that having push to browsers is useful at some level, something has to sit in the middle even if you just want an XMPP passthrough. The XHTML extensions to XMPP sure aren't it. Hopefully Cometd clients and servers will provide just enough structure to allow those kinds of passthroughs to get written in a portable way. If we build just that -- low-latency server push passthroughs to the browser -- I'll happily call Cometd a success.

Regards

by alex at
i think your comments are sound - it is worthwhile finding out where the browser hits the wall and your efforts will certainly bring that to light. i also agree that if possible, stay in the browser. if anything, this model will act as a bridge to the type of client i believe we will be dealing with by 2010-2015 - something like secondlife that introduces tens of thousands of threads into an evnironment that it highly graphical and exceedingly concurrent (not only in terms of user perception, but true network provisioning).
by grumpY! at