A few weeks ago, I spent some time showing an InfoWorld colleague, Mark Jones, how I use Radio. As always in this kind of situation, I was reminded of:
- how much non-default configuration I depend on
- how little I remembered having done that configuration
- how hard it was to articulate, then transfer, that configuration
Another InfoWorld colleague, Steve Gillmor, was watching this, and he said: "You need a deployment descriptor." Exactly right. Now as we prepare to spin out some more Radio blogs, I've taken a first crack at writing that descriptor. Here's the UserTalk code that expresses my core non-default Radio prefs:
aggregatorData.prefs.flScanOnStartup = true; \// I want fresh news at startup.
weblogData.prefs.flPublishOnPost = false; \// I want three buttons: Post, Publish, and Post & Publish, so Post can be used for local previewing.
weblogData.prefs.flTitleAndLinkOnPostForm = true; \// I want to write titled items.
weblogData.prefs.flAutoGenerateLinks = true; \// I want Radio to generate links for those titles.
user.radio.prefs.ctStoriesOnNewsPage = 300; \// I want more than the default 100 stories shown in the aggregator (news reader).
user.radio.prefs.flNewsPageDeleteCheckboxesDefault = true; \// I want those stories checked by default, so I can mass-delete. Then I just need to uncheck the ones I want to focus on.
\// Here's one that stumped me when I set up a friend's blog. I turned on titling, but completely forgot that the item template needs to have <%itemTitle%> added in order for the titles to display. This line rewrites the item template to include that macro:
file.writeWholeFile (user.radio.prefs.wwwFolder + "#itemTemplate.xml",
"<table width=\"100%\" cellpadding=\"1\"> <tr><td valign=\"top\"> <p><b><%itemTitle%></b> </p> <p><%itemText%><font class=\"small\" size=\"-1\"
color=\"gray\"><%when%> <%permalink%> <%editButton%></font></p></td></tr></table>"
);
To acquire this configuration into an instance of Radio, you fire up the GUI app (on Windows, right-click the tray icon, select Open Radio), use CTRL-; to open the QuickScript window, paste in the code, and click Run.
Here's another piece of deployment descriptor we'll probably use to streamline FTP configuration:
uname = "xxxxx"; \// user name
user.radio.prefs.passwords.ftp = binary ("yyyyyy");file.writeWholeFile (user.radio.prefs.wwwFolder + "#upstream.xml",
"<?xml version=\"1.0\"?><upstream type=\"ftp\" version=\"1.0\"><username>" + uname + "</username><passwordName>ftp</passwordName> <server>xxx.yyy.com</server> <path>/x/y/z/weblog/" + uname + "/</path><url>http://weblog.infoworld.com/" + uname + "/</url><mode>passive</mode></upstream>"
);
Using this as a template, another script (I'd do that one in Perl, probably) can swap in appropriate values to create user-specific descriptor text that takes care of FTP setup.
Here's another piece we might use:
user.google.key = "xxxxxxxxxx";
In other words, each user who runs a GoogleBox need not necessarily have to apply for a Google key. A set of them can be administratively acquired; the GoogleBox macro can be included in a standard template; the deployment descriptor can stamp keys into instances of Radio.
There's nothing new here, and you can do this kind of thing in many apps, but it's never as easy as you'd like. UserTalk happens to be a particularly nice way to express preferences in a portable and executable way, but discovering how to do it is a bit of a treasure hunt. Look at the various tables (aggregatorData.prefs, user.radio.prefs, weblogData.prefs, user.google) and files (#itemTemplate.xml, #upstream.xml) that are involved.
I happen to have dug deeply enough into Radio to be able to figure this stuff out, but normal users won't and shouldn't be expected to peer into the entrails. It's the same with, say, Outlook. Since becoming an Outlook user a few months ago, I'm constantly struck by how little of its useful but non-default behavior is available to most users. The problem, again, is one of first articulating, then transferring, the configuration I have achieved.
This is a general problem that I wish all apps would tackle in a consistent way. Given some configuration that varies from the default, enable the user to:
- ask for a description of the tweaks, in some standard XML grammar
- transfer that description (or a subset of it) to another user (or to another instance of the app owned by the same user)
While I'm dreaming, why not use peer-to-peer web services for this kind of thing? If I have Radio or Outlook behavior that you want, I ought to be able to grant you temporary access to my app so you can reach across using SOAP and grab the behavior that you need. The mechanism wouldn't be CTRL-; then QuickScript then Run in Radio, and something equally arcane in every other app. There would be a system-wide standard way to describe, share, and acquire application behaviors.
Former URL: http://weblog.infoworld.com/udell/2002/08/10.html#a378