I said last time that Orbited is the future of the web (I say Orbited specifically, and not just Comet in general, because every other Comet solution I’ve looked at was deeply flawed in my opinion).

Almost every web page could make use of Comet, if for nothing else than embedding a real-time chat about the page. But the world is real-time. News sites should add stories to the main page as they come in. Financial sites should show a running ticker. Game sites should be able to make simple multiplayer games with JavaScript alone, not needing to resort to Java applets or Flash.

Unfortunately, most web developers have no chance whatsoever of building the infrastructure needed to handle Comet apps, and even building on top of existing Comet frameworks is some combination of complex and unscalable. Orbited changes the game completely. It has been carefully designed to do only one thing — handle the Comet side of a real-time web application — while leaving the rest of the application largely unchanged. So well does it hide all of the Comet-related details that a chat application can be written in less than 30 lines of code, most of it configuration code. Orbited gets out of your way.

Though I’ve committed to working on Orbited, I took a look at the other Comet solutions floating around on the web. I came back more impressed than ever with Orbited’s architecture:

• CometD — Michael covered this pretty well in his post, but I’d like to add that I tried to read through the Bayeux protocol, and looked through the CometD twisted implementation and the example code, and couldn’t find any way for my web app to send a message to a particular browser (theoretically, my web app could implement the client side of the Bayeux spec and pretend to be a browser, but this seems like excessive work for such a simple task). Also, messages seem, from my reading of the Bayeux spec, to be passed straight through from one browser to another, without any intervention by my app. Many of the interesting ideas I have for Comet applications would require processing of messages by the server, before they go back to the client.
• FdAjax — FdAjax is built in LightTPD, and based on HTTP. This has the advantage that developers already know how to deal with HTTP. Unfortunately, FdAjax suffers from all of the same problems as CometD, because it’s based on a publish/subscribe architecture. But even worse, where CometD sends JSON data structures back and forth between browsers, FdAjax allows them to send each-other arbitrary JavaScript, which then gets executed by everyone subscribed. This is a security nightmare: Users can force each-others’ browsers to lock up, crash, and delete data on the current page, or could even gather sensitive information from the page and send it to an arbitrary server.
  • [Update, 2007-09-02: I'd like to apologize for not looking closely enough at the FdAjax architecture. I apparently mistook an eval of javascript events sent from a Ruby on Rails server in this FdAjax example for an evaluation of arbitrary javascript sent from one web browser to another. It looks like none of the downsides of FdAjax listed here is accurate, so either Michael or myself will take a deeper look at the FdAjax architecture and post a more comprehensive review in the coming days.]
• Juggernaut — Juggernaut is a Comet solution for Ruby on Rails. It nearly disqualifies itself straight-up, for relying on embedded Flash to make a connection to the client. The Juggernaut developers claim that this is better because it’s not a hack (as the long-polling or iframe transports ostensibly are), but this seems pretty bogus; Flash is not designed for passing events from a server into browser-side javascript, as far as I can tell, so using it for that seems equally hackish to me. I am no fan of Ruby on Rails, and there’s no way that I can tell to use Juggernaut from my Python applications, so it’s out as far as I’m concerned. [Update, 2007-08-27: Michael expounded on these ideas in a long post.]

There are a bunch more frameworks, but I don’t have any time to discuss them here. At some point one of us will have to do a more detailed review of each of these frameworks, and others (maybe even with some diagrams!), but for now, back to Orbited.

Orbited has simple examples to examine, a very simple architecture to understand, and its documentation is improving by the day. It works on all platforms, and its client API can trivially be ported to any programming language that can handle sockets. It cuts out all the gory details, leaving web apps to worry about only their app-specific functionality. In short, it brings Comet to the regular programmer on a silver platter.

Dig in!

This entry was posted on Monday, June 25th, 2007 at 9:45 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.