I suppose it’s a litte ungrateful to say this two days after category support arrived in version 5 of Blosxom (or whatever it really is in Rael’s strange version numbering system). But it’s still true … you should be able to put Blosxom entries in multiple categories. Here’s a great example: this entry could reasonably fit into several other categories (Computers/Internet/Blogging because it deals with Blapp, Computers/SoftwareDevelopment/Methodologies because it deals with bazaar-style development, Computers/SoftwareDevelopment/Tools because it deals with GUI builders, Computers/SoftwareDevelopment/Interfaces because it deals with inherent problems of GUI development … you get the idea).
I understand the need to have a primary category, but secondary categories wouldn’t have to reflect the disk storage model.
Interface Builder is the first GUI builder I’ve ever used that I didn’t really hate. But it still has its drawbacks.
I have quite a few ideas for improving Blapp. I’d love to help Michael McCracken by adding some of these features myself (that seems better than becoming “that pest who asks me for three new features a day”). But that’s going to be difficult, because you can’t really send patches against the objects.nib file.
I suppose this is just a special case of the problems inherent in collaborative GUI development, but it’s still annoying.
James has a real point about Blosxom’s date management. It’s true that the date attached to a blog entry should be a “publication date” rather than the “authoring date” (O’Reilly’s weblog system gets this wrong). But once published the date shouldn’t change. I do sometimes edit entries after publication, to correct spelling or other minor mistakes. But I don’t want the publication date to change.
An additional problem is that blosxom’s permalinks are based on date. If the publication date can change, those links aren’t so perma, are they?
A few years ago, I was excited about a new protocol being developed within the IETF. A close relative of IMAP, ACAP (the Application Configuration and Access Protocol) was designed to allow applications to store preferences and other persistent information (not documents or other big data files, but small stuff) on a server so that it could be accessed from any computer. The classic examples they always talked about were bookmarks and address books. Your browser at work would use and update bookmarks stored on the ACAP server, and then your browser at home could see and maintain the same bookmark list.
For all practical purposes, ACAP is dead. Very few applications use it. Even if they did, organizations and ISPs couldn’t be relied upon to maintain ACAP servers. Too bad. IM clients are the only apps that do a good job of ACAP-style preference storage, and they all use custom mechanisms.
I’m still finding all kinds of things I want to share between computers, though. Bookmarks. RSS feeds. Blog drafts. Notes and reminders. And I also sometimes want to easily share those with others. Not just as in “here’s part of my bookmark list right now”—rather, “here’s access to a portion of my bookmark list; I’ll continue to update it with new stuff that’s relevant to our common interest.”
I’m starting to see that there might be a better way to do this than the ACAP model. Less centralized, less integrated, and more flexible.