In line with my past post about moving forward, we are presenting Orbited at its first conference: AjaxWorld. The conference is located in Santa Clara, CA and will be held September 23 — 26. There will be two presentations: “Comet for Highly Scalable Applications” by me, and “Comet for Everyone: Building Simple, Scalable Comet Applications with Orbited” by Jacob. If you weren’t already planning on attending this conference, definitely don’t come on account of our presentations. Unless your company wants to pay. The conference fee is upwards of $1700 — much more than I would pay for such an event.

Strangely, my presentation is listed under the track “Security and Performance.” I suppose you could look at it as a lecture on performance, but it is definitely not about security. Jacob had the good fortune of being listed under “Advanced AJAX” which sounds a bit more like Comet. It seems to me that they need a “Comet” track because other presentations on this topic are listed under such tracks as “Hot Topic”, “Enterprise Ajax”, and “RIAs in Action”. Go figure. At least they have talks on Comet.

I believe they are recording the presentations and possibly even simulcasting both the slides and video feed. Don’t quote me on that. Regardless, we’ll post our presentation slides and speaking notes here on the blog, after the conference.

Please bear with us. We are attempting to migrate the blog to Wordpress, but the script I wrote isn’t working quite as expected. Hopefully in a day or two the blog will be back to normal.

Why the migration? We have a whole slew of announcements to make and we wanted a nice blog for once.

I guess I’m a year out of date, but I’m just getting to reading various blogs about comet servers besides orbited. I just finished reading Dion Almaer’s post, Juggernaut: Comet for Rails? and I have a few bones to pick.

Some quick background: Juggernaut uses flash sockets to maintain communication between the browser and the push server. Comet has generally been described as an interaction model of bi-directional asynchronous communication… basically adding http-push to the traditional http-pull methods we all use. Comet has been more specifically defined in terms of long-polling and http streaming, methods that both use javascript and http to accomplish the goal.

Towards the end of the article, Dion lists the “advantages/disadvantages of using a flash socket over other methods,” but what he really does is give a factually incorrect listing of reasons he thinks flash is better than anything else without listing a single disadvantage. I’m not sure if this is something Dion wrote, or something Alex McGraw, the author of Juggernaut, wrote. The exact same list appears on the Juggernaut homepage. I’ll assume for the time being that Dion originated this list.

Dion says, in regards to flash socket’s supriority, “It’s much less of a hack.” Yes, many implementations of comet are considered to be “hacks,” but what about Flash? We are basically sticking a flash runtime, an alien piece of software, directly into a browser and then providing crude interfaces for the two to communicate. I have had no end of trouble with memory leaks because of faulty interaction between the flash runtime and Firefox. Additionally, Flash is really a duplication of many features already present in http/browsers. Instead of building on these features, Flash circumvents them and then is crudely hacked wholesale on top of browsers. Perhaps we need sockets and vector graphics, but that should be defined by web standards rather than adobe. But lets assume that javascript comet is a hack for a moment, and Flash isn’t. Whats the problem? With good apis the end-developer doesn’t really care what happens behind the scenes, only that it works. Its a hack that only a few people have to deal with once, and then our problem is solved forever. And those people are already dealing with it… just look at orbited and cometd.

Dion says, “It doesn’t crash your browser (Comet can do this after a while) ” I can only assume he is referring to what happens with novice javsacript programmers keep creating additional XHR objects when trying to implement long-polling, often resulting in memory over-usage and the occasional browser crash. This has nothing to do with the technology though. Its like blaming c because some programmers forget to deallocate memory. Furthermore, HTTP streaming, another common implementation of comet, doesn’t suffer from this problem at all. I have never seen nor heard of HTTP streaming crashing a browser.

Dion says, “95% of browsers support it (flash 6).” But many processors do not, such as AMD64 and ARM. So that means that this technique fails for all iphones. Iphone users, I imagine, will soon be a respectable chunk of users who would be using fancy web applications in the first place.

Dion says, “It’s much easier to implement” This is true… assuming you drop all of http, which is what makes comet hard to implement in the first palce. If you create your own, non-standard protocol for communication between the browser and push server, then its easier to implement. But, of course, your solution only works with itself. What if you want to swap Juggernaut out for cometd? You can’t hold on to any of your browser code, it all has to go. Wheras, if you were using Bayeux (via cometd or an alternative), then you could swap out the backend at will and the browser code need not be changed in the slightest.

Dion says, “It can use a different port - unlike comet - so you don’t need any custom dispatch servlets for forwarding messages through rails to the push server - it can connect directly.” This is factually incorrect. You can use any port with comet. Orbited includes an enlightening example: a web-based irc chat that uses comet. It has static content served from port 80, and has comet served from port 8000. This works, no problem. Don’t take my word for it, you can even find a running instance of the example.

Additional Disadvantages

1. Juggernaut internalizes its publish/subscribe architecture much in the same way that fdAjax or Cometd do. Refer to my sixth point in my previous post, The Failure of Cometd

2. Flash isn’t universal. I mentioned this in earlier refutation, and it is important. There are many users who can use comet but cannot use flash.

3. Flash sockets don’t use http. This is much more dangerous than the obvious lack of standards… it will fail for many “enterprise” firewalls that don’t just blindly look at port numbers. They examine packets and block traffic that doesn’t appear to be http. Users will visit the page and it just won’t work and there will be no explanation — not even an error in the javascript console. We had our network revolution and http on port 80 is all that survived, best to remember that.

4. In soviet Russia, you own flash.

It seems like I just started Orbited yesterday, though in reality I started prototyping it about a year ago. A lot has happened since then and when I step back and look at the website and the project as a whole, I’m very pleased.

I’ve been sticking with low version numbers because I only want adventurous developers who are interested in pushing the boundaries of the web, but don’t mind tracking down a bug or two. In my mind its a small price to pay. Of course, 95% of developers aren’t interested in the least — They’ll adopt once the technology works flawlessly. At this point, I’m pleased to announce that We’ll soon be switching to 0.2.0 development in the repository. If there’s any new functionality you want, now’s the time to say so.

Before 0.2.0 work commences, I want to catch every type of error possible and provide a meaningful report in the error log. The Catch-all functions fine, but its not nice to see cryptic tracebacks all the time. So hopefully over the next couple weeks you’ll know exactly what goes wrong when something breaks.

I also think that Orbited is stable enough for real use. I’m not going to quite call it production ready, but I personally am confident enough to use it in production. The big problem now is opening Orbited up to a wider array of communities. At the moment we only have a functioning python and ruby Orbited client. We need to actively recruit developers from the following languages:

• PHP
• Perl
• Java
• C#/.net

If we have simple chat tutorials for all of these major languages, then we’d be ready to start getting some coverage on ajaxian and other similar sites. There’s only so much the core development team can do, particularly because our skill set is slanted towards C, python, and Java. There are so many application developers out there who use PHP that we cannot ignore them and consider ourselves a serious contender in the space of comet servers.

But Orbited itself is ready for the next set of developers, the slightly less adventurous kind. To that end, we are going to start publicizing Orbited on various developer mailing lists and irc channels. I recently submitted an abstract to the AjaxWorld Conference, as did Jacob. If accepted, I will talk on the share-nothing architecture of Orbited, and the difficulties of scaling pubsub Comet architectures. Jacob will present on Orbited from a more practical standpoint — how to use it to easily create real-time applications.

This is an exciting time, and it’s only going to get better. Twenty years from now all of these problems will be gone — boring old news. But right now we are poised to invent solutions and really push the envelope. That’s exciting.

Announcing Orbited 0.1.5

• New website: www.orbited.org (thanks to Jacob Rus!)
• Live Demo! Get help from out irc channel… in your web browser!
  • www.orbited.org/livehelp (thanks to Jacob Rus!)
• Major stability fixes
  • No longer crashes with malformed input
  • Catchall error reporting (includes line number)
  • Proxy fix
    • somehow proxy lost HTTP/1.0 support (missing content-length header case)
    • Caused it to not work with Pylons/Paste. now it does
• New Pylons Demo.. tutorial soon to come (thanks to Matthew/desmaj!)

After a couple days working on it, Orbited Live Help, which I mentioned last month, now seems to mostly work. There are still a few features I want to add to it, and a couple bugs to work out, but you should be able to click that link, and use Live Help to join us in the #orbited IRC channel, where the Orbited developers can answer your questions. Or if you like, just stop by to say hello.

The server-side code was left nearly untouched, from Mario’s WebIRC. But I rewrote all of the browser-side HTML, JavaScript (using jQuery), and CSS. The result is something that I think better serves its purpose as both a demonstration Orbited application (though it’s perhaps less impressive, it’s simpler to use), and as a live support chat (where extra features just get in the way). Also, it no longer has a garish color scheme: Sorry Mario, but CSS “red” should almost never be used in a design.

The JavaScript code is much cleaner, even if some functionality was removed. As one example, the code to handle the orbited event where someone leaves the chat room went from this:

function userLeft(data) {
    chat_box = document.getElementById(data[1]+'text');
    div = document.createElement('div');
    div.className = "left";
    sender = document.createElement('span');
    sender.className = "sender";
    sender.innerHTML = data[0];
    message = document.createElement('span');
    message.className = "message";
    message.innerHTML = data[1];
    linker = document.createElement('span');
    linker.innerHTML = data[2];
    div.appendChild(sender);
    div.appendChild(linker);
    div.appendChild(message);
    chat_box.appendChild(div);
    if (currentChan == data[1]) {
        box = document.getElementById('box');
        box.scrollTop = box.scrollHeight;
    };
};

To this:

function userLeft(leaver, channel, message) {
  $("<div class='informative part'></div>")
    .html("<span class='user>" + leaver + "</span> " + message + CHANNEL)
    .appendTo("#chathistory");

  removeName(leaver);
};

Needless to say, I vastly prefer the latter for clarity.

The new chat now highlights lines where someone mentions you by name, and the next version will handle tab completion of nicknames. I’d like to prettily style the user list, and maybe add some icons to it, but there’s plenty of other things to do around here in the mean time.

[Update, 2007-08-29: Add image that actually shows some people in the channel]

When I was experimenting with Orbited early on, before it was an Open Source project, I became very, very annoyed by browser security. Specifically, for some god-forsaken reason it’s just this side of impossible to do cross domain scripting even when you are running both servers, and on the same parent domain. Sure, at this point it seems straightforward to me, but that’s only because I spent a year tackling the problem.

If you are interested in cross-domain scripting, read what some of the experts have done. Such as Abe Fettig. For the other 99.995% of you who don’t give a rat’s ass, I included a proxy in Orbited.

The proxy, as you may well already know, overcomes the problem of cross-domain scripting by putting Orbited in front of your web application such that the browser thinks orbited is the Comet server and the web app.

The proxy is a testing and development tool though. In a production environment it is a pretty bad idea to use the proxy. Not only will it make it much harder for you to scale your application and achieve true redundancy at all tiers, it will use at least twice the cpu as you should be using.

Even so, it turns out that 90% of developers only want to use the proxy. From what I’ve gleaned, most people want to create prototypes or in-house apps. I think that the idea that anyone could use Comet is so new an idea that developers of large web applications are staying away. It’s going to take a new startup (maybe meebo) getting huge before all the other sites out there start integrating Comet.

In the mean time, as the prototypes roll, I’m left holding the bag. I had absolutely no idea what I was getting into when I included the proxy.

Proxy v1

When I first started, I was using CherryPy as a backend for all of my test and demo apps. I shut off CherryPy’s multi-threading because I wasn’t interested in generating all sorts of thread synchronization bugs. As a result, I had to also disable keepalive. With a single thread and keepalive, one user would tie up the server.

Given that keepalive was off, it was very clear how to proxy incoming requests. Examine the url. If it looks like an Orbited url, then hold on to the connection. Otherwise, check the proxy rules and send it on its way. After I designated a connection as proxy, I never looked at it again.

Proxy v2

I wrote an app that used more than one thread, and I enabled keepalive. Whoops. Suddenly my orbited requests were sometimes going straight through to the webapp. Whats going on? Well, my proxy would look at the first request coming down the pipe and then never look again. So the second request, which was for Orbited, got proxied as well.

Some long hours later, and I had a new proxy. It would look at all the data as it flowed from the client to the server. At the end of each request, it turned the connection back over to Orbited. When the next request came down the pipe, Orbited ran its usual check to see if it was for Orbited or for the proxy.

Proxy v3

So along comes a django developer. He writes a simple version of the cherrychat app in django, sets up the proxy, and nothing happens. No requests ever make it back from django to the proxy. And get this — the error reported is: “<type ‘exceptions.TypeError’&rt;: exceptions must be classes, instances, or strings (deprecated), not type” with no useful line number.

Turns out pyevent 0.3 and python 2.5 on ubuntu 7.04 causes exceptions generated by Orbited to be reported incorrectly. So I patched pyevent 0.3 and tried again. After much grief, the problem became clear. Django uses a rarely seen feature of HTTP/1.1 known as Transfer-Encoding: chunked;. It allows Django (or any other web framework) to render templates incrementally and send the results as they are available. The reason this wouldn’t be possible without chunked transfer is that in HTTP/1.1 you need to specify the Content-Length header before any content. But Django can’t know how long the content will be until it’s rendered.

So I rewrote the proxy yet again, because the previous code base wasn’t very conducive to this sort of interaction. This time though, the rewrite took about two hours because I had the old version to reference. After I finished, my Django tester disappeared never to return, apparently discouraged by the previous lack of Django support. I tried to do my own Django thing but I got lost. And I couldn’t make it use HTTP/1.1, much less chunked transfer encoding. So someone please test this when you get a chance.

Proxy v3.1

After coming all this way, I stopped supporting a subset of HTTP/1.0. That is, If not Content-Length header is specified, the connection just ends when it ends. But I was assuming, as per HTTP/1.1 that it meant the length was 0. This wasn’t a very involved fix, but I’d like to thank Matthew (desmaj) for finding this bug.

So the whole Ordeal was definitely worth it — I know all about HTTP Protocol and how it effects comet, proxies, and comet proxies. The proxy is more stable, which is great. I think that it will continue to be the main method of deploying Orbited applications because it’s just so much easier. It makes the difference between a 10 minute tutorial and a 30 minute tutorial. Just because of the proxy which isn’t a viable real world tool, we probably have a 1000% higher retention rate of prospective Orbited users. It just goes to show you that ease of use is what makes something popular. No one cares about scalability until after they’ve chosen a framework.

The original Orbited (then known as “Orbit”) logo, was tossed together by one of Michael’s friends in about 5 minutes. It has a certain charm in its complete simplicity, but I was never much of a fan, and decided that though I’m not much of a logo designer, once I joined the team, the logo had to go, and if someone else wouldn’t step up to make a new one, I’d have to do it myself.

See the original for yourself:

I doodled in Illustrator, trying to incorporate various types of “orbits” into the word “Orbited.” After a few hours, I had found a font that I liked well enough (Cronos), with a very round O that worked reasonably well as a planet or star around which to draw an orbit. After a couple of hours of fiddling, I had created a brush stroke swoosh tail with a splotch comet, orbiting the O (yes, I realize tails on comets point away from the Sun, and don’t trail behind them):

I passed this around to a few friends, who pointed out that the black text was nearly unreadable on the dark blue background. But a couple of them, including Eben, also disliked the font and the brush stroke. He was nice enough to spend some time brainstorming with me. The two of us passed back and forth a number of ideas for adding depth to the orbit line.

I liked the concept of using the line width to convey depth, as in the third of the above attempts, and the approach worked well with a clean modern font like Futura (which conveniently has a very nice round capital O), and so I finally ended up with something that looked like this:

But in passing this around to friends, a quite common response was that the new logo was too cold and impersonal. They generally preferred a re-colored (to avoid the black text) version of the brush stroke logo.

So, combining (in my opinion) the best of each, I stuck Futura into the brush stroke comet orbit, and jazzed the whole thing up with some warmer colors. The result can be seen on the main website, but here it is for good measure:

Hopefully this one is good enough.

• Rewrote the Proxy
  • Django didn’t use to work. Does it now? Calling all Django Developers
  • Added transfer-encoded: chunked
  • New keepalive Engine
  • Arbitrary keepalive timeout
  • Fixed missing transport bug (doesn’t crash now)
• New User Group @ Google Groups

CherryChat and the CherryChat tutorial have been on the website as long as I’ve known about Orbited, but finally they not alone, having now been joined by a RailsChat tutorial. Ruby on Rails is kind of a beast: it installs hundreds of (from my point of view) useless files and directories, and requires a developer to run a script to create a new section of a site. But I suppose it works well enough for what it’s designed for. After giving up on the discussion in the #rubyonrails channel, I asked some Ruby programmer friends how to save state, and they explained to me that adding $ before a variable name makes it global. Not long later, RailsChat was finished. The client-side code in RailsChat is pretty much copied directly from CherryChat. And the resulting apps behave pretty much identically.

It is however amusing to compare the directory structure of each version:

CherryChat:

RailsChat:

And of course the money shot (a working chat app!):