Blosxom Up and Down

2010/7/20

** Blosxom Up

My latest greatest idea for managing my personal web sites, which I
put more than a few hours over the Sea Day three-day weekend trying
to pull off, was to set up a simple Blosxom configuraton on each of
the ten-or-so sites I want to make public. Besides the standard blog
and news feed generation, I planned to use a few select plugins to
add comment (writeback) and web-based editing (wikieditish)
functionalty.

I would add to the blog article templates links into the file system,
organized as per cavenet and tir, where the served content source
files are stored. Blosxom has the virtue that it can serve content
from potentially any subtree in the host file system. It's not
restricted to content within the web server subtree. For example,
with Blosxom it's simple to set up a blog for content stored n my
gopher hole subtree.

Finally, I'd link together all my sites on the "papa's universe" page
with a rawdog meta-blog pullng from all my sites's Blosxom-generated
feeds.

(Needed short-term enhancements: support article file extensions
other than 'txt' ('html',...); proxy access for gopher and
non-standard port servers)

This configuration would have given me basic maintenance access to
files through both WWW and shell, and good visibility/accessibility
to my public sites.

** Blosxom Down

However, a weekend of tinkering with Blosxom has cooled me (again:
I've put expectations in Blosxom but been disappointed by it more
than once before) on centering my web site management on the program.

Before I explain the latest cooling down, let me say that Blosxom is
a very impressive and elegant piece of software. Even though it has
not been actively developed for several years and community interest
hs been fading, I have repeatedly revisited it and found it to be the
blog engine that is by far the closest to supporting the style of
blogging that  *I* want to do. Working with the program this past
weekend, I again impressed by the economy and flexibility of the
core script and the plugin system.

My problem with Blosxom is with the flavours system. While it shows
glimmers of the same cleverness that inspire the rest of the program,
I feel like it is a component that has been stretched beyond its
original intent, and for me beyond the boundary of usability.

Flavours are Blosxom's mechanism to support customization of the
blog's appearance, and limited to this original purpose they are
effective and efficient. A flavours is defined by a set of up to five
template files. Blosxom allows the administrator to define multiple
flavours which can be selected easily via the CGI query string
(article pseudo-file extensions in the URI query string actually
select the flavour for formatting the generated page).

The problem is that flavours are also the only way to present user
interfaces to functional extensions. Many plugins are delivered with
a custom flavour or require modifictions to existing flavours in
order for blog users to have access to the plugin
functionality. These flavour modifications must be integrated into
the current look-and-feel of the blog and with each other, and
propagated to all relevant flavour templates. Multiply this over the
ten-or-so sites I intend to operate and the effort required for
maintenance and synchronizing enhancements becomes discouragingly
scary.

At least scary enough to make me think that coding my own feed
generator, edit CGI, and comment system might be the easier choice.