Tangled in the Threads

Jon Udell, January 21, 2002

Radio UserLand 8

The next turn of the wheel

Radio UserLand 8 is the latest installment in a story that began almost 15 years ago. The plot has taken twists and turns that have left many people (including me, at times) bewildered. Sailing on a tumultuous sea, UserLand's founder, Dave Winer, has had to tack frequently -- towards the GUI then the web, towards the server then the client. Along the way, certain principles have remained constant:

Tuning into Radio's big picture

My own Radio blog documents my first few days of fiddling with Radio 8, so you can check there for the blow-by-blow. Here, I want to focus on broader themes and tell the big story. There's so much history behind this product, and there are so many layers to it, that it can be hard to discern the basic storyline. Here are some key plot elements.

Writing for the web

Dave's premise, and mine too, is that the web has been in a state of arrested development since shortly after its birth. It was meant, from the start, to be a two-way collaborative writing environment, not a one-way publisher-to-reader environment. Tim Berners-Lee's ur-browser was, like the W3C's testbed browser Amaya still is, an HTML editor as well as viewer.

I've written elsewhere about the universal canvas. There are many deep issues here that won't be fully resolved for a long time. But things are moving, on several fronts, in the right direction. Part of the answer is consensus around XML as a common data format, and we're getting there. Part of the answer is a ubiquitous replacement for the browser's hopelessly primitive TEXTAREA widget. The Microsoft DHTML edit control, exploited by Radio and other web-writing systems, is a flawed solution in several ways -- IE-only, producing HTML rather than XHTML or XML. But the fact is that for the 90% of users who are running IE browsers, it works well enough -- and (to my taste) better than the Java-based alternatives I've tried. By that I mean: well enough so that, once other pieces of the puzzle fall into place (like content management, syndication, and community), the resulting network effect will, I hope, force the issue and make native XML-capable WYSIWYG editing a first-class capability of all browsers (or whatever replaces what we now call browsers). That said, writing off 10% of the world's web-writing population isn't OK.1 Interim options could include a Mozilla native solution, a Java-based solution, or (since Radio is a commercial product), an industrial-strength and Netscape-capable implementation of the edit control, such as Ektron's eWebEditPro.

Although I haven't focused here on Radio's built-in outline-oriented editor, I don't discount it either. In the new version of Radio, it's pushed far into the background -- wisely, I think, since it confused many more new users than it delighted. But this is an old technology which has lots of future use left in it, and room for growth. Once we take writing in XML for granted, we'll need and want structure-aware editors. Meanwhile, long-time Frontier users -- and I am admittedly not one -- can do outline-oriented HTML editing today in Radio.


Like other script-and-template-driven web programming environments, Radio is extensible in a million different ways. Since it does not function primarily as a server, but rather as a client-based tool for writing and website management, it may not be immediately obvious why, never mind how, to extend it. Here's why: because optimization and customization of our writing and communication tools is one of the great challenges of the decade. None of the web's amazing programmability does us a lick of good when it comes to improving how we communicate, since we still communicate mainly in fixed-function email clients that we can't layer interesting applications on top of. Bringing the httpd to the client, and harnessing the web's programmability for client-side apps, was what inspired my dhttp project years ago, and Radio has this same vision.

Now what about the how? One approach is to use Radio's built-in scripting language. For example, a few days after Radio 8 shipped, a Radio version of a Manila-oriented bookmarklet appeared. If you poke through that script, you'll get an excellent idea of how Frontier scripting can interact with the local httpd to improve the experience of writing for the web -- in this case, by jump-starting a blog posting directly from the web page that you want to cite and annotate.

Honestly, though, I'm unlikely to become a serious Frontier hacker. But that's OK. Radio is open at a couple of other levels too. One is the filesystem. Although Radio has an object database at its core, it is also filesystem-driven in useful ways. So for example, the category display in my Radio blog is controlled by a file called /radio/www/#navigatorLinks.xml. When Radio 8 shipped, this file didn't automatically update to reflect newly-added categories. A tool that will do that bit of synchronization could be written in Radio, but needn't be. An external process can as easily notice changes in /radio/www/categories, and synch the #navigatorLinks file accordingly. This kind of openness is really convenient.

The icing on the cake, though, is the SOAP support. It's easy for Radio 8 to to consume, or produce, SOAP services. So a developer who's happiest in Perl, Python, or Ruby can connect into and out of Radio without needing to become a Frontier expert. What matters (as Microsoft, with .NET, also deeply understands) is that you can script integration, not in what language.


The currency of blogging communities is awareness. It flows within these communities, and increasingly (thanks to RSS channels and cross-posting APIs) it flows across them too. This mode of communication can resemble email, yet differs from email in ways that are important but hard to describe. Nevertheless, I'll try. Email is a message addressed to a person or group, whereas blogging is a message addressed to a space. The relationship of people to spaces is many-to-many, and fluid. Blogging communities wired together with publish/subscribe technology form knowledge networks, and the people joined to those networks are the routers. What happens in a network whose routing function is governed by human intelligence? Lots of people, me included, expect powerful emergent behaviors. But we won't know until the phenomenon reaches critical mass. Getting us there is UserLand's unwavering mission, and with Radio 8 the company has taken another big step forward.

1 Speaking of that 10% write-off, a longstanding gripe of mine regarding Frontier-generated sites is their table-heavy and thus Netscape-4.x--unfriendly formatting. When Radio 8 debuted, and attracted broader interest than earlier versions had, this issue resurfaced. Dave says he'll fix this, and also make the generated HTML valid and CSS-oriented for the benefit of Mozilla as well as IE. Good!

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He is the author of Practical Internet Groupware, from O'Reilly and Associates. Jon now works as an independent Web/Internet consultant. His recent BYTE.com columns are archived at http://www.byte.com/tangled/

Creative Commons License
This work is licensed under a Creative Commons License.