Infrequently Noted

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

Something's Always Wrong

Like a sled dog who would gladly run himself to death, I seem not to be able to kick the habit of over-working, especially not on things that I find interesting. If my interests and efforts were mostly aligned at Jot, they're now identical vectors at SitePen. My full-time job is now what I once did as a hobby, and my hobbies are all the interesting little technical pursuits I've put off in the last couple of years. Add a large dose of Lutheran guilt about doing the right things the right way and a seeming inability to say "no" to people, and sleep seems like a particularly quaint anachronism.

Were it not for Jennifer, the woman I love madly, I think I'd be clinically insane by now. I'm good at last-minute panic. Things like "did we turn off the stove?" and "maybe I should double-check when that flight is leaving...". Jennifer, on the the other hand, is the organizer. Instead of leaving important details for the last minute, she ensures that big things happen at all. Months in advance, she'll be asking "so [insert name of band] is coming, do you want to see them?", and thanks to that (and a little "where did we put the tickets?" from me) we've been able to see Buddy Guy, BB King, and Toad The Wet Sprocket this summer.

Toad was a special treat since they've been broken up for years. Despite it carbon-dating my highschool years, I've got something of a soft spot in my iTunes playlist for old Toad stuff. Even new "Ok Go" doesn't make me as happy cycling through my playlist during these endless hours at the terminal. While their set the other night was pretty heavily scripted, they still sounded as good as any of the studio recordings. Thanks to Jennifer, I got out of the house for some celebration after turning my brain to mush in preparation for a talk at LinuxWorld and I finally got to see a band I've been listening to heavily for nearly a decade.

No matter what you may think of the music, it's hard to imagine a better gift.

Sweet, Blessed Bandwidth

For a while now there have been flyers in the elevator of the building where we live advertising network service through the 10baseT network that was presciently added to the original design of the place. It helps that the building is fairly new, having been constructed in the wake of the '89 quake and the destruction of the Emabarcadero Freeway. At some point in the late 90's internet service had been provided to every unit via a shared T1 line, but that died about the same time that's sock puppet hung it up, or went back into the drawer, or wherever it is that sock puppets go in the afterlife. Thankfully everything old is new again and the service has been resumed by a new company, albiet with a fatter pipe (T3).

Contrasting VVD's installation process with SBC's is a study in how a small company can beat the living crap out of entrenched players. Of course, the local phone and cable monopolies don't usually tend to sent an exceedingly high bar for customer service, but when you can select (online) what time you'd like the install (to within the hour) and the guy shows up on time, the phone company should start to worry. A lot.

When I lived in Madison, I happily gave my business to TDS instead of the local telco monopoly, and I was always impressed with their service and general geek-friendlyness. It seems that VVD is a bandwidth provider in the same mold. After the initial "install" (lighting up an ethernet port) I found myself staring down some weird speed issues. In my haste to configure the Airport for the new service instead of the previous PPPoE setup, I neglected to reset the ethernet duplex settings. Halarity ensued while I tried to figure out why the OS X boxes (which don't support Selective ACK) saw roughtly 1/10 the upload bandwidth of the linux boxen (which do). Some dinner and a whack-the-forehead moment later and we've now got a network connection that's faster than anything I've used on a daily basis since college.

A better, synchronous connection and the ability to stop paying monopoly rent for that's what I call progress.

Cometd, Bayeux, and Why They're Different

Ajax has been stupendously successful in capturing the imaginations of webdevs in part because of the backlog of demand for better interactivity in browser-based apps, but also because it's stone-simple to implement. One of the biggest problems facing the adoption of Comet is that it's, by definition, not as simple. It's usually not possible to take ye-old-RESTian HTTP endpoint and suddenly imbue your app with realtime event delivery using it unless you want your servers to fall over. The thread and process pooling models common to most web serving environments usually guarantees this will be true. Add to that the complexity of figuring out what browsers will support what kinds of janky hacks to make event delivery work and you've got a recipe for abysmal adoption. That complexity is why we started work on Bayeux.

Bayeux is a JSON-based protocol for clients to register interest in events and for servers to deliver them in a more timely fashion than Ajax-based polling allows. The goals of the Bayeux spec so far have been to:

As a result we've variously rejected plans that involved implementing some subset of XMPP in JSON or actually tunneling XMPP over some other carrier. JSON libraries are available almost everywhere and you can't beat the speed of eval for message deserialization on the client. It keeps things fast, simple, and pluggable. Authentication and authorization, while being given spots in the protocol, have also been left entirely to implementations to negotiate. The result has been that implementations have gotten off the ground very fast. Since the protocol doesn't specify any guarantees around durability, entirely ephemeral event busses can be as conformant as MOM-style guaranteed-delivery systems.

So what, then is Cometd and how does it relate to this Bayeux specification? The short answer is that Cometd is a project to provide several reference implementations of Bayeux and to evolve the spec until it's good enough for some other group to take over maintenance. Bayeux and Cometd are two complimentary parts of a plan to tackle the complexity around building and deploying comet apps, and we're hoping for many independent Bayeux implementations outside of the Cometd project. For more interactive apps to finally take off, we need a set of portable concepts about how this kind of message passing should be handled in much the same ways that Ajax could be thought of as "RESTian web services for browsers". Today lots of folks are thinking about event busses under the buzzword banner of SOA, but hopefully in the same way that REST was the lighter but easier variant of SOAP for doing request-response web services, Bayeux can be the less-sophisticated (but easier to use) alternative to exotic schemes for connecting MQSeries and TIBCO to browsers.


There's been a lot going on in the world of Comet in the past couple of months. Post-JavaOne activity from the Java side has been tremendous and I was unaware of most of it until Greg Murray and Greg Wilkins mentioned the various efforts to me. <a href=">Greg's got the details of most of the Java activity, save Sun's Comet-on-Grizzly announcement. As was widely covered elsewhere, the excellent work of Juggernaut has demonstrated the Flash XMLSocket approach and integration into a widely-used, modern web framework. Of course, Nevow has been shipping some great Comet infrastructure for Twisted developers for years, but that's been a pretty small group of folks.

In other news, the Cometd project has been accepted into the Dojo Foundation. With multiple demonstrated implementations of the pre-0.1 Bayeux spec, we've got lots of momentum around solving the "last mile" problem for events to browser. Work on the spec has been bursty but I think that's contributed to keeping it simple. Right now we're tackling topic/channel globbing, event timeouts, and multiple event delivery semantics. Perhaps the most exciting thing to Bayeux to me, though, is that implementations of it lend themselves to extension and experimentation with implementing new styles of Comet transport mechanisms. The current Bayeux client in Dojo supports 4 different transport types with more on the way.

I think it's going to be interesting to see how much the ability of platforms and languages to handle Comet workloads impairs or enhances their chances. Can Ruby and PHP pull off something that'll allow them to scale? Will Twisted Python, Erlang, or full-stack Perl finally have their days in the webdev sun? Will great implementations in Java and C# hold the dynamic languages at bay?

I can't wait to find out.

Mea Culpa

The tone of my last post was entirely out of order. There's a serious UX issue at hand and my writing did nothing to bring that discussion to the fore. I hope Jason will accept my apology.

Older Posts

Newer Posts