17:05: Blosxom timestamps, in the face of revisions...

The way Blosxom deals with timestamps is great--fantastic, effortless, beautiful, perfect... until one decides to revise an entry, the entry gets a new timestamp, and the original timestamp is lost to the winds because, while unix has multiple `last modification' timestamps, it has no concept of `file creation-time'.

That's OK, actually--because, even if it did have creation-timestamps, we'd all end up wanting some other sort of metadata; inside the filesystem per se basically isn't the right place to stash all of the metadata about which anyone cares. And that perspective is bolstered by the fact that we do have tools above the filesystem layer that can keep track of all sorts of metadata, and more than just a single level of metadata--more than a single revision of the data, too!

Enter Revision- (or Version-) Control Systems.

But Blosxom doesn't know anything about any of these tools.

But Blosxom has a plugin-architecture.

But the plugin-architecture doesn't have any hooks specifically for replacing the timestamp-logic--the the coupling of entry-timestamps to file-timestamps is hard-coded deep in the middle of a bunch of other logic that's only tangentially related (if it's even related at all).

So, I could write a plugin, but I'd have to duplicate a bunch of logic just like the existing solution does, or revise Blosxom to give the plugin-architecture cleaner lines of delegation.

If I'm going to be doing major surgery on my weblog-system, though..., I wonder if it'd make more sense to just switch to PyBlosxom--maybe it's got a more workable design to it?

The revision-control system that I'd be using would be Bazaar (it'd be useful for my wife, not just geeks like me), which has (nay--is) a Python API that I could use, so maybe switching to PyBlosxom is even more tempting.

I'll have to give PyBlosxom a deeper review than I've done previously (a glance had me thinking that its raison d'etre was that the author couldn't be bothered to learn Perl, which would be..., well..., idiotic: why split the development-community like that, just for the sake of it?).

[Reply]