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:
|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:\radio\www\index.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
Things to look forward to
Former URL: http://weblog.infoworld.com/udell/2002/01/20.html#a19