untitled

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:

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.

Former URL: http://weblog.infoworld.com/udell/2002/01/20.html#a19