How Catkin measures up
2003-05-04 19:23:53 UTC
As the author of Catkin, I suppose I should be thinking about mpt's requirements for the ultimate weblogging system. Catkin doesn't score brilliantly, but that's ok, because I'm not writing a weblogging system for mpt. That said, a lot of his requirements are obviously good things. Let's look at how Catkin compares.
A win to start with: Catkin is GPLed.
And we do well on data storage too. mpt says that the system must work with a free database and allow entries to be exported to XML. Catkin goes one step further. In Catkin, everything is stored in XML already. I don't need to mess around with databases or exporting.
I'm quite fond of Catkin's URIs, but they only partially meet mpt's requirements. I do have file extensions on the names, and I agree that in an ideal world they wouldn't be there (for the default representation at least -- I'm not sure I'd go so far as to say that any alternative representations should be retrieved by content-negotiation alone). I don't use the YYYY/MM/DD directory structure, which also rules out time-specific indexes within each directory. I'm not too bothered by that, though perhaps it would be a good thing.
Catkin doesn't do summaries, which would probably be a good thing. It also doesn't store any sort of objects with the entries. If you want to include an image, you have to upload it to your site manually.
Catkin also doesn't use categories, which rules out a lot of mpt's requirements. That's largely because I don't really believe in categories. They might get added in as a plugin though. I haven't given much thought to what form that might take, and I don't even know whether I'm prepared to write it myself. (The astute reader will notice that Catkin doesn't actually support plugins of any sort. I'm working on it. It might arrive in the 0.3 series, or maybe 0.4.)
Catkin produces RSS files, though obviously not for categories.
Catkin doesn't ping weblogs.com. That's definitely plugin territory though. There's no way that's going in the core. The same goes for CC licenses.
Converting Slashdotted pages to static then back to dynamic doesn't make much sense to me. If you can speed up page generation when you're being Slashdotted, why not keep it fast when you're not being Slashdotted as well? Anyway, Catkin currently uses static pages all the time. Hopefully there will come a time when it can serve pages dynamically, and, being even more hopeful here, it would be nice if it had an effective caching mechanism as well.
As for interfaces, I readily admit that Catkin doesn't score as well as it should here. At the moment there's only the web interface, and that's not very powerful. Someday I'll do more, but that's low priority at the moment. (I don't quite get the thing about LinuxSTEP. I think I understand the point about creating incentives to use free OSs, but I don't see why LinuxSTEP is therefore preferable to GNOME or KDE. I must be missing something.)
Catkin scores very badly on backwards compatibility. Importing is theoretically quite easy, but no one's written any actual code to do it. I don't suppose Catkin will ever support other URI styles.