Serendipity

From: Nick Leverton
To: blosxom-devel@lists.sourceforge.net
Subject: Re: [Blosxom-devel] Project status?
Date: Tue, 31 Jul 2007 13:03:54 +0100
Message-ID: <20070731120354.GC25392@leverton.org>
In-Reply-To: <A10A315B-8AD7-4FC8-8205-146494EBDDD4@barijaona.com>

On Tue, Jul 31, 2007 at 07:11:40AM +0300, Barijaona wrote:
> I'd prefer not change the spirit of blosxom, but recognize that its
> learning curve is really frustrating. So I suggest the following
> evolutions :

I very much agree that Blosxom is still a useful piece of software but
desperately needs updating in some areas. I write as someone who's set
out to evaluate several weblogs lately, including Wordpress, but who
has come back to Blosxom as by far the lightest-weight weblog for my
pathetic little 80Mb virtual hosting - not to mention having the least
complex code to hack on :)

For instance, many useful plugins are undergoing link rot as their authors
convert to other blog software and take down their Blosxom installations.
I spent ages last night looking for autoblock, textile and twikirender,
any one of which would have done to simplify my post formatting - all
have apparently dropped off the net. I can probably hack up a textile
plugin myself, it looks trivial, but I'd prefer if I didn't have to !

> - one should consider rehearsing blosxom's regarding its default
> interpolate routine and XML feed. Most users are expecting something
> more up to date in these areas, so why not give them out of the box
> the functionalities of interpolate_fancy and atomfeed ? The current
> situation makes blosxom appear really outdated.

> - there are a couple of blosxom starter kits (including a selection
> of plugins and flavours) floating around. We could encourage the
> creation of similar kits through "official" changes to the
> configuration variables in blosxom.cgi.

I agree it would be a worthwhile effort to gather together a set of
"recommended" plugins which we can then document, support, bugfix,
and accept enhancements for. Depending of course whether the plugin
authors agree, but most of them seem to have used the Raeality licence
so it ought to be a formality.

This then gives a way to move Blosxom forward by taking the canonical
plugins as mainstream, so that the relevant features will work in the same
way for all plugin authors. This will reduce the interdependency problems
I've run across, which are not always even declared in the perldoc.

I don't know if the Debian maintainer Gerfried Fuchs is here
directly ? I helped look at a security issue in the Debian version,
http://bugs.debian.org/423441, and though it's not an exploitable issue
in mainstream Blosxom I would very much like to improve the coding style
(apparently left over from Blosxom's earliest days) that let the loophole
creep in.

I have other vaguer ideas too, along the lines of overhauling XML and
interpolate() as you do, but just getting blosxom back into development
would be a great start !