Leaving Frontier

    Leaving Frontier


    Leaving Frontier

    Wednesday 14 December 2005

    It is with great sadness that I consider leaving the Userland Frontier / Radio website renderer (that I’ve been using since the early 1990s) for something more modern. For reasons of personality and finances the visionary ideas core to this great rendering engine have been prevented from evolving. A once-vibrant community of supporting developers has been allowed to wither, good ideas have been lost because of active discouragement for an add-on library, and the critical number of users required to support and maintain such an environment hasn’t been reached (not surprising, given the hostile, dysfunctional direction we’ve experienced).

    Even Dave Winer’s decision to preserve some of his work by releasing the Frontier kernel as open source can, most charitably, be considered far too little, far too late.

    There have been no significant advances since the program was migrated from Mac OS 9 to Mac OS X, almost a half-decade ago. There’s been no leveraging of the amazingly robust services provided my OS X (such as for-free built-in spell-checking) or anything else. The process seems more and more creaky.

    Trying to get Frontier / Radio to generate valid CSS with XHTML has been the breaking-point for me. As I investigate my options and play with the various tools out there I realize that I’m not sure what I need. With an eye towards moving to something modern, I’ve been considering what capabilities I need for this site.

    So, in no particular order, are what I’ve found so far:

    The concept of hierarchy

    I have a big website. All over the place I use the nesting of directories to impart context, organize, and to keep the thousands of images used.

    Programs which try to keep everything in a single amorphous cloud of “web” just don’t work for me.

    The filesystem, please

    The use of proprietary databases (Frontier) or more modern relational databases (as other programs use) seems useless to me, as I’ve never used any storage features which can’t just as easily be implemented in a file system (which is more easily backed up, more robust, more easy to fix in case of corruption).

    A glossary and a way to substitute values therein

    In Frontier the page title is inserted into a system-wide glossary. Any page can link to another by referring to the title; “Leaving Frontier” becomes .

    Additionally, I can substitute human-readable values easily. For example,

    {glossSub(“Leaving Frontier”, “the last straw”)}

    yields , which makes for more human-readable context.

    Global access to images

    In Frontier I can say something like

    #imgFolder “some/path/to/a/folder”

    {imgFileRef(“happy.jpg”, “Happy, a dwarf”)}

    {imgFileRef(“dopey.jpg”, “Dopey, another dwarf”)}

    and a variant,

    {imgFileRef(“walt-disney.jpg”, “Walt Disney”, imgFolder:”some/other/folder”)}

    both of which make it easy to refer to images from any web page. Frontier figures out the relative addressing to the image in question. (I actually coded an

    of images, so that this became legal:

    {imgFileRef(“walt-thumbnail.jpg”, “Walt Disney”, linksTo:”walt-big.jpg”)}

    which made my travelogues a lot more fun.

    Linking images to glossary items

    One of the cool things about UserTalk is how these sorts of things work together, so the following is valid (and damn useful):

    {glossSub(“Rome”, imgFileRef(“rome.jpg”, “Rome”))}

    Yep, that’s how to have an image link to a particular page. Sweet.


    Investigations of what makes for a modern, easy-to-use system include something like Markdown.


    The navigational links you see at left are useful. The renderer is smart enough to figure out which page is ‘this page’ and doesn’t generate a link to itself, giving a visual clue to the reader.


    In addition to the leftLinks, having ‘previous’ and ‘next’ navigation aids on pages is great. Currently the renderer looks at a list which I order, but I’d be happy if it just went by the filenames (at least for the first pass).

    weblets / conditional compilation

    I need to do lots of things for weblets, that is to say, sub-areas of the website. The leftLinks for this area, for instance, make no sense for any of my , each of which has its own series of pages.

    And there are some pages which will have no local leftLinks at all. For those I’ll probably leave things empty.

    Static Rendering

    This whole kit and kaboodle needs to be uploaded to some industrial-strength ISP. No rendering on the fly, please. Let me grind through this page, pages changed since last rendering, or all my pages.

    pointing to the local URL

    Within a web page (generally within the template pages) it’s valuable to be able to point to the page being generated, to provide a value for a page-validator, for example. I’ll need some equivalent to {url}.


    Being able to generate a listing of all the web pages below some arbitrary point – sort of a site map – along with a short description (perhaps extracted from a comment on the page) is incredibly useful. The pages would have to be presented alphabetically by (1) document name or (2) document title. (The current renderer only does the latter, and that loses in some important instances. There have been fixes to this, but they’ve been lost due to the lack of a community repository. Meh.)

    anything else?

    This seems to be what I’ve found on my first pass through my site. Being able to do this in some other Content Management System would be the first step away from Frontier / Radio.

    This page is part of the .

    all this webring’s pages;

    another page;

    your page to this webring.

    Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me . Thanks!









    This page


    1993-2006 by ,

    via the Creative Commons License. Questions and comments? Send

    to the Geek Times Webmaster. (Domain and web content hosting at .)

    Leave a Reply

    Your email address will not be published.