Plans change.
I had planned to have the new dsandler.org stuff up this
week, but it just didn’t work out that way. The code that runs the site
is old, cobbled-together and horribly busted; I decided, after some
anguished introspection, that I’d prefer to spend less time fixing my
weblog software, and so I’d use some OSS package instead of developing my
own weblog engine again.
The whole point was to reduce the amount of hassle, and here
I am, knee-deep in hassle with pyblosxom. I think the idea
behind it is great—entries are Plain Old Files (like my current
implementation), flexible categories and URI syntax, and implemented in
Python (so I can hack away at the parts that don’t work). I find myself
hacking away at the whole thing, because in some ways the architecture
is fundamentally flawed.
For instance, I’d like it to show just one day at a time in the
default view of any category; OK, I can write a callback plugin to cut
off the entry list after the first visible day. But what about “next
day” and “previous day” links? Pyblosxom has these great date URLs; out
of the box, it will show you a day’s entries if you append /YYYY/MM/DD
to a URL. So, given a date, it’s easy enough to create links which
blindly point you forward and backward in time, but I want to skip over
days which have no entries. Sorry! Once your callback function gets the
list of entries for a given day, it’s already erased all knowledge of
the rest of the weblog, so there’s no way to search the rest of the
database for the next and previous valid day.
This ties into the other fundamental suckage of Pyblosxom: It has no
concept of indexing for its entries. It is incredibly slow on
the dsandler.org database, because there are a couple of
thousand files it must stat() and sort. A database-backed
weblog engine would keep a by-date index of the entries, but Pyblosxom
does all kinds of perverse destructive things to the list of entries as
it scans the filesystem, making indexing impossible. The pyblosxom
people must either not use their weblogs a lot (!) or must render
every possible page to a static HTML file, which really defeats the
purpose (to me) of a dynamic system.
In short, hassle.