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:
- make event delivery fast
- keep it simple
- provide extension points in the protocol
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=http://blogs.webtide.com:80/gregw/2006/07/25/1153845234453.html">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.
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.
Update: read this first
Jason Fried is full of shit.
It's really sad to see a supposed champion of user experience equivocating instead of dealing with a serious experience issue. Initially, the party line was that cross-browser WYSIWYG wasn't possible. After we put that misconception out to pasture with
dojo.widget.RichText and showed that the UI doesn't have to be complicated to be functional (
dojo.widget.Editor2), it's amazing to see 37signals adopt all the classic signs of NIH-ism. Why would someone use Writeboard if they weren't interested in sharing what they write? Almost all of the UI of Writeboard that isn't taken up by content is dedicated to collaboration. The argument Jason makes takes the side of some mythical hermit writer who wants a crappy text editor that doesn't have auto-save, is difficult to resize, can't load files from disk or save to it, doesn't feature spell-checking on most platforms, and can hardly function when not connected to the network. Umm...yeah.
Folks writing stuff down for consumption by others are necessarily concerned with how it's presented to those other people. Sure, browsers make it a royal pain to do WYSIWYG reliably and consistently across browsers, but is the fact that it's hard somehow a good reason to prevent users from expressing themselves with better fidelity? I argue that it's not, esp. when you're charging people money for a service. Folks who want to learn YAML can download any of a hundred Open Source wikis and start debating the finer points of reStructuredText vs. Textile vs. Markdown vs. MediaWIki syntax. These are people who don't need 37signals to help them identify with the system model.
Which leaves us people who want to share things with other people, don't really give a shit about figuring out what clever combination of keystrokes is going to make something bold, and would like their investment in UI idioms to be portable to the web. I humbly submit that this market represents most humans who interact with computers. When it comes to UI, only be different when you can be demonstrably better.
There are a lot of UI problems left to solve with WYSIWYG on the web today. What we can already do in browsers is a pretty poor baseline for what we should be giving users and hugely smart people have been hacking on the problem for a long time. It's about time that we started evolving some truly "web-ish" idioms about how WYSIWYG should be done and how we can keep users happy but still informed about the limits of the medium. In the Dojo editor, we attacked this by stripping down the number of options to the point where the toolbar represents only what browsers natively support editing on, which falls neatly in line with what they reliably render without losing the semantic of what the user meant to convey. The new "snap-floating" toolbar in Editor2 is designed to keep the chrome in place when it's needed but not break the page-centric idiom. The new editor in 6Apart's Vox drops strange popup windows for much more intuitive in-page dialogs. The latest version of TinyMCE is also showing real creativity in helping users get where they're going without sacrificing the "webishness" of the editing experience. I'm sure that the creative guys over at 37signals can do even better should they set their minds to it. Sadly, they seem too busy telling paying customers that they're wrong.
Less is not better, better is better. That better may correlate with less some significant percentage of the time is in no way causal.
Hot in the heels of my former employer (Jot) reviving their blog from the dumpster of disuse and market-speak crap, we've set up a new blog for SitePen.
I'm lucky to be working with some great people on stuff we care deeply about. From DHTML UI tricks to keeping the web an open, neutral platform, SitePen has a lot to say. Obviously with just one intro post, it's hard to justify to adding it to your RSS reader just yet, but give us a couple of weeks. I think you'll be glad you did.