Orbited needs to have its client API ported to many languages. No one was stepping up to do this. So, despite a complete lack of Ruby experience (none of us have any Ruby experience as far as I know), I spent a few hours porting the Python simple client to Ruby. It was surprisingly straight-forward. The code undoubtedly looks like Python code, but that’s alright. It only has to work (It does what it is supposed to do from IRB anyway), it doesn’t need to look pretty; the first Ruby user who wants to use Orbited for real work will undoubtedly fix it up.

With Ruby down, only Perl, Java, PHP, and .NET are left, of our top priority languages. That means we’ve done 1/3 of our target client libraries! Feel free to pitch in a port to your favorite language; with moderate experience in the language, the port shouldn’t take more than an hour or two.

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!

Orbited Paper Delayed

I mentioned previously that I was working on a paper about Orbited. It includes pretty diagrams and succinct technical explanations and comparisons to other technologies using good, hard data.

Unfortunately, that paper is going to be delayed. I’ve got a lot of stuff going on, with the new job, and I’ve had to travel a fair amount recently for various reasons. More importantly though, my Co-author Professor Art Lee has and will be occupied for a various number of reasons including the purchase of a new house and his kids coming home from school for the summer.

It’s okay though — There aren’t many conferences with upcoming due dates that I’m interested in debuting Orbited to academia. I’ll keep you posted on news about the paper. I expect work to resume in late August or early September.

I’ve heard some complaints about the current Orbited logo. For one, it’s missing the “ed” in Orbit_ed_. Okay, I’m sorry — A friend put that together in just a few minutes. So if anyone out there wants to do a better job, I am all for that. I am low on time myself and I think I should spend the little time I do have strategically.

The Logo is often the first impression a prospective user has about a project. We want something that conveys a sense of community, but without looking too relaxed. We don’t want to scare away the Enterprisey folks right off the bat. So something that’s cute, but clearly professionally done. [Update, 2007-08-13: A new logo has been designed.]

Hello orbiters,

Last week, over some coffees, Michael revealed the future of the web to me. It took him a good fifteen minutes to fully explain Comet, the technology behind the browser side of the Orbited, and another fifteen to spell out the strain Comet applications place on traditional web servers, and Orbited’s architecture. By the end of the half hour, it was clear to me that Orbited is the way forward: I wager it will be in wide use within a year.

I’ve never been a fan of web applications from a user interface perspective, as compared to the power, flexibility, and responsiveness of desktop apps. In short: web applications, on the whole, suck. And one of the main reasons they suck is because nothing happens in real time. Events on the server side can’t trigger the browser’s interface, until Comet. Comet lets web apps handle real-time applications like board games or chat, and Orbited makes Comet easy. Today, I still prefer a well-designed desktop application to a web application whenever possible. But I can access a web app from an internet cafe in Mexico, or a friend’s Windows machine. A web app I create can likewise be used by anyone with a computer, anywhere in the world. And with Orbited, web apps take another leap forward.

I’m sold. I’m joining the project, with a few things on the todo list:

• Proofread the website content. Michael is a great programmer, and a decent writer, but terrible at catching his spelling and grammar errors.
• Get rid of that god-awful logo. For one thing, it still says “Orbit”. I’m hoping someone else steps up to fix it, but in another couple of weeks I won’t be able to stand it any more.
• Try to get client APIs going for a few more languages. I don’t have any Ruby, Perl, or PHP experience to speak of, so any such ports should be a good learning experience.
• Fix up some of the diagrams for the site, and for Michael’s in-progress paper. He makes diagrams with MS Paint. And while they’re informative, they are a bit, shall we say, homely, for my taste.
• Make a Tic Tac Toe demo app.

In the meantime, I’ll be spending the next few days at Apple’s Worldwide Developer Conference in San Francisco. I’ll be back on this blog sometime after that.

The fellow who gave me the WebIRC idea recently brought to my attention the shocking truth: WebIRC is NOT in color. Well, was not. I was bummed for a little while, and when I got home I wasted some time trying to write an easy fix (hah!), but then God spoke to me. I said: “GO FORTH AND TYPE ‘MIRC COLOR JAVASCRIPT’ INTO GOOGLE.” The first hit, mirc_colorize.js, by my hero, Chris Chabot, happened to save the day. One line, folks, and WebIRC assaulted my eyes with all the colors of the mIRC.

Then I took a nap.

• New pluggable transport System: Uses setuptools; Write transports as seperate modules and it finds entry points at run time
• Added iframe_alert: Not much of a point, but shows how you can control the browser remotely
• Tutorial: using orbited with ruby
• Tutorial: RailsChat (thanks to Jacob Rus!)
• IRC Channel on freenode: #orbited
• Demo: WebIRC (Thanks to Mario Balibrera!)

I would also like to note that I’ve begun work on an Orbited Paper, with my esteemed colleague Professor Art Lee who is an expert on distributed Java systems. He’s interested in getting into python and he’s also interested in comparing Orbited against the Java Cometd implementation.