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.

This entry was posted on Monday, August 27th, 2007 at 10:19 am 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.