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 pets.com'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 bandwidth...now that's what I call progress.
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.
Older Posts
Newer Posts