Jon Udell: Radio

Adventures in content management

2002-12-09T13:28:22-05:00

A while back I set up a category for tracking my InfoWorld columns and stories. It's a handy feature of Radio (and of other blogging tools, such as Movable Type) -- just pick your category names, and tag one or more of these names onto an item to assign it to one or more categories. As always, though, this little exercise in content management wound up being trickier than I'd planned.

When I created my InfoWorld category back in October, I populated it with a bunch of URLs for everything up to that point. I didn't want to dump all this to my homepage, but fortunately a bug that had prevented category-only posting had been fixed, so that was no longer a problem. Great! That meant I could subtly introduce the new feature by just adding a link to my lefthand navbar.

It was a little odd that all the entries appeared to be Oct 7 2002 rather than their real issue dates, but OK, I could live with that. It made me realize, though, that adjusting date order wouldn't be too easy. Even if I went through and tweaked the dates in the database, Radio processes items in numerical order by posting. It would take more intervention than I have stomach for to overcome that numerical bias.

There was one unintended consequence, though. My page that lists all items in the blog, driven by a storyList script, listed all these Oct 7 2002 items, and that seemed like overkill. So I adapted it like so:

if ( t.flNotOnHomePage == false )
{...}

to exclude category-only postings.

That worked fine for a while, but recently when somebody asked for a link to a story, I noticed that I couldn't find it. Why not? Oh, of course. Categories, like the home page, display a fixed number of days' worth of items. I use the default: seven days. There were a lot of items for Oct 7 2002, but once I'd added entries on six subsequent days, older items began to fall off the event horizon.

Is there a name for the kind breakage that occurs when unchanged code is confronted by more or different data than you were expecting?

The items-per-page setting is systemwide, so bumping it up for categories would make the homepage unwieldy. In any case, a really long category page would be unwieldy for the same reason. So I decided to use a variant of the storyList macro to enumerate just the titles and links of items in a category. Here is that other macro. To make it run automatically, I followed the same technique as described here -- namely, call the macro from a story, and arrange for a system agent to touch that story when an item is published. That forces the story to regenerate, call the macro, and upstream. In order to remember how to do that, I had to search my own blog, which I suppose is both an indictment and a testimonial.

There was one more unintended consequence to deal with. Radio distinguishes between the display name of a category and its filename. For example, the display name of one of my categories is "Web Services" but the filename is "webServices." "InfoWorld" becomes "infoworld." (This scenario of course sets you up for sneaky NT-versus-Unix gotcha: it works on NT because NT is case-insensitive, but fails on Unix which isn't. For that reason, I always recommend testing static namespaces on Unix. Was Windows' case-insensitivity supposed to be a time-saving feature?)

The script, when enumerating postings, needs to find a category-posted item by its display name. But when it forms the URL of the item, it needs to use the filename. So I had to replicate that logic. It's in system.verbs.builtins,radio.weblog.newCategory, which I guess is part of Radio's lizard brain. I found the code, and simplified it a bit using a regular-expression search-and-replace -- something the lizard brain probably didn't know about.

All's well that ends well. Here's the new version of the InfoWorld category, also linked to from the navbar. I haven't propagated this technique to my other categories yet because, frankly, I'm wondering if this posting will bring a better solution to light.

These things are, as I said, always trickier than you expect. Content management systems try to make reasonable assumptions about the display of time-ordered and categorized data, but when the relationships between those two evolve, as they inevitably do, assumptions break down. Tools that would make it easier for users to do wholesale recategorization or reordering of data are rarely available, for the very good reason that they are hard to create. My guess is that Radio and MT probably hit the sweet spot. They deliver enough categorization and sorting to satisfy most users. Doing more would entail complexity and effort that most users would rather avoid. If you really want to, though, the code's open and you can find a way.

CxO bloggers

2002-09-06T08:32:16-05:00

I'm particularly interested in C[ETI]Os who are using blogs to communicate goals, strategies, and perspectives. So I've added a feature to this blog that helps keep track of these CxO bloggers.

This was also a chance to put Marc Barrot's excellent activeRenderer to work. Although his blog is called SLAM (for Site Logging and Monitoring), and is nominally about system administration, Marc has become deeply fascinated with outline processing and has built some great tools to extend Radio's outlining capabilities.

The "how this works" page, linked to from instances of activeRenderer, documents how to use it. Briefly, here's what I did:

1. Wrote the outline in Radio's outliner, where it's easy to maintain.

2. Saved it to the /radio/www/gems directory as cxoBlogs.opml, which in turn causes it to upstream to http://weblog.infoworld.com/udell/gems/cxoBlogs.opml.

3. Added the following to my homepage template:

<%activeRendererHeader () %>
 <%activeRoll (
 "http://weblog.infoworld.com/udell/gems/cxoBlogs.opml",
 title:"CxO bloggers" )%>

Nice! Thanks, Marc! This is an ideal way to manage a chunk of structured data compactly and elegantly.

Marc Barrot's outline renderer

2002-03-28T10:12:24-05:00

The following macro:

<% renderCss ( "C:/Radio/www/instantOutliner/jonUdell.opml", "instant" ) %>

will render my instant outline like so:

(removed, was becoming too much to include here)

Nice, Marc! As you can see on Marc's blog, this is an elegant way to manage structured elements that can be included anywhere. The CSS integration, which I'm not using here, adds another dimension of control.

Productivity is the endgame

2002-03-28T00:17:52-05:00

Here's another great way to use the W3C XSLT service:

- Dave's outline

- Jake's outline

- My outline

Outstanding work on the XSLT/JS/CSS renderer, Joshua! It's amazingly cool to be able to export that capability to the world by blogging some URLs, eh?

As to the meaning of what's happening here, some comments picked out from Dave's stream-of-consciousness outline tell the story:

We've been using this tool since November, internally at UserLand. We shipped Radio 8 with it. When we switched over our workgroup productivity soared. All of a sudden people could narrate their work. Watch Jake as he reports his progress on the next project he does. We've gotten very formal about how we use it. I can't imagine an engineering project without this tool.

Eventually this way of working together will happen for all professions. This is the killer app behind blogging, I'm pretty sure of it.

So am I. That said, there are many, many more pieces that need to fall into place. People are going to look at this and say ugh, the outliner's UI sucks. Which it does. They're going to lament the lack of robust search, persistent URLs for outline subitems, and a million other things. And they'll be right. But these will be good problems to have, if what precipitates the whining is a general adoption of a style of networked communication based on structured messages and a willingness to work transparently. We can solve those merely technical problems. What's been missing is a context in which to address them in productive and useful ways.

"All of a sudden people could narrate their work. Watch Jake as he reports his progress on the next project he does."

This is the key. It's not about XML, or HTTP, or outlining. It's about people evolving to the point where they publish what they're doing, and subscribe to what other people are doing, in just the right proportions, so that there's maximum awareness of shared purpose but minimal demand on the scarce resource of attention.

Don't just focus on the outliner. Look at how the people who are proficient with it structure their work. That's the endgame. Software tools (like the one being boostrapped here) are a necessary, but not sufficient, means to that end. Once people figure out how networked communication is really supposed to work, though, software's going to get much more interesting than it ever has been.

Ask and ye shall receive: Hannes Wallnofer's Bloggenmoz

2002-03-14T09:53:29-05:00

Hannes Wallnofer writes:

Welcome to Bloggenmoz!

This site was created to document my attempts to add support for the Blogger API directly to Mozilla Composer . What this means is that people should be able to post to their weblogs directly from the HTML editor that comes with Mozilla. I've started coding over the weekend and already have a functional prototype. Here's a screenshot: (Click here if thepopup script doesn't work) You can get my current code from the download page . You'll also find installation instructions as well as some notes and caveats. Please remember that this code is experimental! This project was inspired by Mike Lee's MozBlog, a Mozilla extension thatis embedded in the browser window and allows for quick posting of smallertexts (think bookmarklet). In contrast, Blogger API support in Composer wouldbe ideal for writing longer texts, something that is very unconvenient withbrowser-based solutions. There's more to come soon - stay tuned and let me know what you think!

I think things are getting really interesting, again! If you try this, remember to enable this Pref. Here are the settings I'm using in the Publish dialog:

XML-RPC URL	http://localhost:5335/RPC2
WeblogID	home (why?)
Username	from this Pref
Password	from this Pref

It's so nice to have the use of a table editor, once again! As Hannes notes in his blog, there's more to do. This really does want to be embedded in Radio's UI, not external to it. And of course the recent innovation around RSS titles is, I guess, not yet available through the Blogger API, so I'll probably go back and title this item. Oh, and I had to tweak some image URLs in source mode in order to refer back to Hannes' site. All this can get sorted out relatively quickly, once there's a critical mass of people who are in a position to use, and appreciate, the full power of hypertextual writing with words, pictures, tables, math, and vector graphics. Bring it on!

(PS: Hannes, some words ran together and I had to do some additional touchup in Radio's editor. But...this is way cool! Thanks so much!)

Titled items added to Radio!

2002-03-11T19:53:41-05:00

Thanks so much for adding the title feature!

Should the Link field default to the permalink of the item being written?

Hmm. There's a difference between what I'd want the HTML reader to see:

Most excellent!

and what I'd want the RSS reader to see, in a titles-only view:

Most excellent!

2002-03-10T23:34:29-05:00

Helping Marc with a Radio script

Marc Barrot's still stuck. I'm hardly an expert on this stuff. If anyone wants to correct or augment my advice, please do.

2002-03-04T10:54:42-05:00

Oops, broke the News page

Steven Vore pointed out that the previous item breaks the News page. I removed the angle brackets surrounding the word "title" as a workaround. If you've already received the feed containing that item, though, you should probably unsub/resub. And, I guess, avoid using amp-lt-semi until this gets sorted out.

Mark Pilgrim ran into the same thing.

The uses of indirect discussion

2002-01-31T21:14:39-05:00

Sam Ruby and I have been having this oddly indirect discussion here on Radio, and it's made me think. At first glance, the indirectness seemed like a flaw in Radio. Were it a discussion system, like Manila and countless others, we'd be talking back and forth directly, and others would doubtless be chiming in too.

Many believe that every document on the web -- even every paragraph or sentence -- should be, at least potentially, the root of a threaded discussion. I have thought so too, for a long time. But now I'm wondering whether this "bug" in Radio is really a feature. Writing for Radio feels different than writing for discussion groups. It feels more like writing for publication. It makes you want to think through what you say more carefully, and not shoot from the hip.

I've been a writer all my life, and one of the lessons I've learned is that the process of writing -- done slowly and reflectively -- is closely related to the process of learning. I don't really know something until I can explain it, and I can't really explain it until I can write it.

In this age of instant communication and message overload, it gets harder and harder to find time to think things through. Maybe every document on the web shouldn't also be a conversation. Maybe we also need some quiet places in which to think and write.

2002-01-24T09:22:04-05:00

Sam Ruby writes:

Many SOAP stacks these days come with automatic roadmap dispensers. Simply append a "?WSDL" to the URL and out pops the description of the service. Many alpha males will tell you that they don't need to ask for directions. But I suspect that these roadmap dispensers will be heavily used.

Absolutely. When services are consumable by namespace completion in an editor, like so:

Then we get the kind of network effect we all want. What matters is not only the number of SOAP endpoints that exist, but the number that are actually used, and "roadmap dispensers" are critical. Automatic testers are darned handy too:

Necessary? No. Desirable? Hugely. I want this, everybody should want this. And it looks like we're going to have it. The tension here, as always, is between what is considered the bare minumum interoperable core, and what is considered optional. If WSDL is not considered core, and isn't everywhere, that will compromise the vision displayed in these images. If it is considered core, it raises the bar on resource-constrained implementors. There's an inevitable and natural tension between these two positions.

John Robb wrote privately to say:

Jon,

You are pointing to images on your Weblog that are located in your desktop folder (so they are not visible). They have been upstreamed to your cloud.

Thanks, John. This is exactly what I was testing. Here's what I learned:

An image in or below /www/radio/images will be upstreamed. (I think automatically, but maybe it has to be kicked -- Publish->Entire Site?)
Such an image, loaded into a separate IE window, can be dragged into Radio's MS DHTML edit control, and will be inlined.
By default, the URL is like 127.0.0.1:5335/images, not ./images.
I guessed that Radio would translate that on upstreaming.
It didn't.
So you have to use Source view in the editor, and change 127.0.0.1:5335 to .
Then, Publish directly. If you switch back to WYSIWYG view, the editing component (which Radio does not control) will revert you to 127.0.0.1:5335.

Obviously most users are not going to figure this out. Just as, years ago, most did not figure out how much writing and illustrating and cross-referencing power was built into the mail/news client that they ran every day. We have a chicken/egg situation here. Hypertextual writing, using words and pictures and links, with fluid transitions among local and remote resources, remains difficult. This exactly parallels the WSDL discussion. Until users can take for granted that in any web writing environment, images and text can be dragged and dropped, and everything will just work, we'll keep missing out on an important network effect.

And now, I'm going to switch back to Source view and re-fix those links which the Edit control has re-broken. Radio can fix this particular glitch by rewriting what the DHTML edit control does, before upstreaming. But the general issue of how we get to a universal canvas remains, well, a general issue.

PS: One more wrinkle. Using . was OK for the homepage, but I forgot this item is echoed into categories and an archive page. So I'm redoing the . as a full reference to the public site.

2002-01-22T19:03:53-05:00

Sam Ruby writes:

Dave, I guess your target audience is people like myself and Jon Udell who "have for years been in the game of dynamically generating statically-served sites". What about the hordes of unwashed masses who aren't so inclined and seem to prefer Integrated Development Environments (IDEs)? Wouldn't the world be a better place if there was some widely adopted way to describe the messages in some structured way amenable to consumption by such tools?

It's true we are geeks who will hack page templates in vim or emacs. This incarnation of Radio, though, delivers the basics -- not just simple blogging, but also receiving/filtering/annotating/retransmitting flow -- in a manner that I think will be directly approachable by the proverbial "mom".

Richer descriptions of messages, and tools that exploit those richer descriptions, will make life even better for "mom" -- if this extra sophistication doesn't gum up the works.

Is WSDL gum, or grease, or maybe a little of both?

2002-01-21T12:35:00-05:00

Here is the Radio version of Manila Express:

RadioExpress

It's a shortcut to dump an URL into a new blog entry. I made this entry using it. Thanks, Mike! Lots of useful stuff in there to learn. Question for Mike (or anyone) about this explanation:

However, R8 default form editor does not support receiving default text via external forms. So I changed it and repackaged it in the form of a new R8 page.

I see that. In many places in RU, there are callbacks to things that live outside radio.root, so you can intercept/change core behavior without getting overwritten. I gather that this form editor is not one of those things?

2002-01-21T10:55:36-05:00

I can almost edit in Manila from Radio. The Radio port is open to the world (at the moment), and the Edit in Radio button from Manila can successfully send the message that pops up the editor in Radio. But, where's the Add Manila Site function in Radio, nowadays? Can't find where to put the Manila password, so the response on saving the item is: "Can't create new message, incorrect password." No big deal. I've never been a user of the Frontier outliner anyway. Just curious to see how the pieces fit together in the new configuration. ...

2002-01-20T14:56:11-05:00

I just noticed another synch problem. Even after a successful Publish->Entire Site, the calendars on some not-recently updated pages -- like http://radio.weblogs.com/0100887/categories/databases/ -- didn't change. Evidently that template is not sent through the renderer when the site is regenerated?

Oops, I'm wrong. I see why not. Each of those calendars reports on activity for its own category. This is a feature, not a bug :-)

2002-01-20T13:45:11-05:00

AOL buying RedHat?

http://www.byte.com/tangledthreads/thread.jsp?forum=263&;thread=8266

Some kind of buglet there.

a&b

a&amp;b

http://a&;b

http://a&;amp;b

http://a&;amp;amp;b

2002-01-20T12:16:24-05:00

UserLand's Jake Savin says the navlinks problem is fixed. I've updated radio.root, this post will test the outcome.

Hmm. It didn't. Was that because of the unnecessary index.html's in the navlinks? Shouldn't matter, but I'll retry.

OK, I edited out those index.html's and now it worked. Probably the timestamp on the navlinks xml file needed to change in order to trigger the refresh. Which leads to the next question. My guess is that while this page (the homepage) now has a regenerated navlinks section, there are other pages (like the category pages) which have yet to be regenerated, and will require a Pubish->Entire Site. Testing...

... yes, that was true. For example, the navlinks at http://radio.weblogs.com/0100887/categories/security/ were still of the form http://radio.weblogs.com/0100887/categories/rss/index.txt. Now, I'll Publish->Entire Site...

...yup, that took care of it. Thanks, Jake! FWIW, this all makes perfect sense to me because I have for years been in the game of dynamically generating statically-served sites, and am familiar with the tradeoff of mass-uploading sets of generated pages in exchange for simplicity and performance on the server side. That said, I don't think it will be clear to a casual user why some parts of the generated site can get out of synch with others, and when and why to regenerate everything.

While we're at it, here's another experiment. I'm trying to understand the relationship, in Frontier/Manila/Radio, between the object database and the filesystem. I earlier asked, for example, how to rewrite the navlinks xml file dynamically when new categories appear. It occurs to me this needn't be done in Radio at all. Clearly an external process can notice new subdirectories under /radio/www/categories, and adjust the navlinks file accordingly. The question is: which takes precedence, the contents of the file, or the contents of the database? Let's find out.

To do the experiment, I created the category called Categories. Initially, nothing appeared under /radio/www/categories. To materialize the directory, I guess cross-categorizing this posting under both Radio and Categories should do it...

...right. Now, let's pretend I'm a process (running in Radio, or ouside it, shouldn't matter) that notices the appearance of this new category, and edits the navlinks file accordingly. I'll just simulate that by a hand-edit.

Yup, that did it. Cool! In contrast to, say, Zope, it's convenient that much Radio behavior is filesystem-driven and -accessible.

As before, the navlinks update propagates only to the pages affected by the subsequent update. In this case: the homepage, its permalink file, the affected category html pages, and the rss files associated with all these. A Publish->Entire Site is needed to make everything consistent.

OK, that worked, though there was a hiccup:

Event	What happened	Time	Secs
Weblogs	Notified Weblogs.Com that your weblog has updated.	12:46:11 PM	1.433
Upstream	67 files: index.html, mySubscriptions.opml, index.html, radioBadge.gif, xml.gif, header1.gif, header2.gif, header3.gif, headerBg.gif, userLand.gif, help.gif, htmlEditor.gif, editbutton.gif, bottomBg.gif, bottomLeft.gif, bottomRight.gif, leftBg.gif, rightBg.gif, topBg.gif, topLeft.gif, topRight.gif, bg.jpg, curveRest.jpg, dot11.jpg, dot21.jpg, dot22.jpg, dotBG.jpg, menuBG.gif, menuLeft.jpg, userLandLogo.gif, rss.xml, directory.opml, index.html, 15.html, 18.html, 19.html, 20.html, rss.xml, index.html, 15.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, rss.xml, index.html, 20.html, rss.xml, 15.html, 18.html, 19.html, 20.html, testFrameIt.html, test.html.	12:46:09 PM	66.055
Upstream	Can't upstream because "Can't find a sub-table named "C:radiowwwindex.txt"."	12:44:40 PM	11.183

This suggests that these issues are interrelated. At some point, it might be desirable or even necessary to have a Publish->Affected Pages which computes and transmits the minimal subset of pages required for consistency. And/or, it would be very useful to integrate with server-side-include when that's available on the host -- since #navigatorLinks.xml is logically just navlinks.ssi on an Apache server like the one that's being used in this case. That would cut down on a lot of unnecessary traffic.

None of these are major issues, just things I observe because I do a lot of this kind of thing myself. Here's the big picture I'm taking away from the last few days of experimentation:

Things to like

This is a powerful tool for folks who, unlike me, are not in the business of (and in the habit of) dynamically generating statically served sites. And also for folks like me who want to apply these techniques for informal communication -- especially routine business communication -- as opposed to formal kinds of website publishing.
The HTML edit control (also used in other environments) is a great 80/20 solution -- that is, it solves 80% of the problem for 20% of the implementation hassle.
The self-updating nature of the software is nifty, in particular its ability to absorb changes to radio.root without a restart.
The automatic RSS-ification of everything is of course (always has been) extremely powerful. By empowering people to trivially both consume and produce channels, it enables them to become routers in a knowledge network. Integration of categories into this flow is something that will have profound network effects.
The software is open to integration in several crucial ways, notably via the filesystem, SOAP, and its scripting engine.

Things to look forward to

Fuller utilization of the local webserver. It only runs a management/editing UI now. In many cases, especially on intranets where firewalls don't get in the way, upstreaming to a community server would be redundant. You'd like to use the full power of that desktop webserver to directly host what you publish. At the same time, you'd like it to be full WYSIWYG, in the sense that you wouldn't have to upstream and then check how (or whether) .txt files got converted to .html files. This would also pave the way for utilization of the native fulltext search, a key issue for KM environments.
Distributed community services. The blogging community that Radio attaches to by default is great fun. But again, from an intranet/KM perspective, people want to form their own communities that aggregate channels, measure flow and popularity, and manage change alerts. Here too the desktop engine has the power to do these things. It's only a question for UserLand as to how to commoditize, package, and market these kinds of things.

2002-01-19T12:12:07-05:00

Upstreaming is much happier now. (Though, it being Saturday morning may have something to do with it as well. Yesterday's problem may have been congestion?) But there's still a rendering problem that causes my navigator links to reference .txt rather than .html on the community server. And this is true even though I'm seemingly forcing the issue like so:

The categories really are there, but the generated site can't reference them.

Spent some (well, a lot of) time spelunking the rendering code in radio.root, got a good sense of how the engine works, and then sensibly decided .... let Dave fix it :-)

Note that while it seems odd that the same files appear multiple times in the upstream log, they really are different. For example, 18.txt and rss.xml occur under each of my categories as well in the main archive.

Event	What happened	Time	Secs
Weblogs	Notified Weblogs.Com that your weblog has updated.	12:03:09 PM	1.003
Upstream	60 files: index.html, mySubscriptions.opml, index.html, radioBadge.gif, xml.gif, header1.gif, header2.gif, header3.gif, headerBg.gif, userLand.gif, help.gif, htmlEditor.gif, editbutton.gif, bottomBg.gif, bottomLeft.gif, bottomRight.gif, leftBg.gif, rightBg.gif, topBg.gif, topLeft.gif, topRight.gif, bg.jpg, curveRest.jpg, dot11.jpg, dot21.jpg, dot22.jpg, dotBG.jpg, menuBG.gif, menuLeft.jpg, userLandLogo.gif, rss.xml, directory.opml, index.html, 15.html, 18.html, rss.xml, index.html, 15.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, 18.html, rss.xml, index.html, rss.xml, 15.html, 18.html, testFrameIt.html, test.html.	12:03:08 PM	68.065

2002-01-18T19:30:48-05:00

Hmm. I'm trying to fix a few things:

force category links to .html rather than .txt
eliminate the ": " in the main template

In order to do so, I'm trying to Publish->Entire Site, since I'm not sure how to push those fixes individually. But, this keeps happening.

Event	What happened	Time	Secs
Upstream	Can't upstream because "Can't read stream because TCP/IP error code 10060 - Connection timed out."	7:24:55 PM	103.883
Upstream	Can't upstream because "Can't find a sub-table named "C:radiowwwcategoriesdatabasesrss.xml"."	7:22:10 PM	8.005
Upstream	Can't upstream because "Can't read stream because TCP/IP error code 10060 - Connection timed out."	7:21:32 PM	83.416
Upstream	Can't upstream because "Can't read stream because TCP/IP error code 10060 - Connection timed out."	7:19:35 PM	84.015
Upstream	Can't upstream because "Can't find a sub-table named "C:radiowwwimagesbg.jpg"."	7:17:41 PM	4.283
Upstream	Can't upstream because "Can't read stream because TCP/IP error code 10060 - Connection timed out."	7:16:27 PM	102.116

2002-01-15T23:15:14-05:00

This discussion snippet asks and answers some more questions that I immediately had. In particular, it clarifies that only static HTML is delivered to the public host (which by default is Apache). That explains why there's no built-in search -- it's functionality that's not exportable as static HTML.

That said, let's not sneer at static HTML. In fact, Radio is using a technique that I continue to rely on heavily in managing websites. I call it dynamic generation of statically-served pages.

For example, I put the following into /radio/Macros/test.txt:

on test (s) {
return ("" + s + "")}

and then I put this into /radio/www/test.txt

#title "test"
<%test ("the sample text")%>

My local server responds to /test.txt like so:

the sample text

And the public server gave the same result in response to /test.html.

When I change the call to:

#title "test"
<%test ("some different text")%>

It changed in both places.

However, when I changed the underlying macro to:

on test (s) {
return ("(" + s + ")")}

The bolded, rather than underlined, rendering appeared only locally, not on the public server. To force the change to appear on the public side, I tried deleting/recreating /radio/Macros/test.txt. That didn't do it. I did succeed, finally, by deleting/recreating /radio/www/test.txt, the page that uses the macro.

Perhaps there's a synchronization strategy I don't yet understand. Or perhaps there are some kinks to be worked out. But in general, for the kinds of communication that Radio is meant to enable -- collaboration, knowledge management -- the marriage of a dynamic content renderer with a static page server can be highly practical and efficient.

Hmm. The synch issue are interesting. For example, I just changed my navigator.xml to include links to the Radio and RSS categories. They appear on the home page, and on the Radio category page, because these were both refreshed by my last post. However they don't appear on the RSS category page, and won't, I guess, until I route something there that forces a refresh. Is there a "Force Refresh of Everything" option?

Later...OK, found it. It's in the GUI-based tool, rather than the browser-based one. Radio->Publish->Entire Website did the trick.

2002-01-15T22:08:37-05:00

This observation about no self-hosting was something I noticed right away. ...

2002-01-15T21:45:05-05:00

Now I want to recategorize the posting, having decided that the newly-created RSS category is more appropriate than the original Radio category.