New web content engine, part 7

I made a few more modifications to Rm. I took it easy this weekend — I’ve had a number of important design bits at work, so there wasn’t much brain-juice left over for recreation this weekend. So there’s a number of changes to Rm that aren’t enabled yet.

I discovered that one bug that I was dreading trying to fix I had fixed while hunting down some other issues. I also finally installed a version that plays my MP3s with a flash player.

I also have to give props to Kyle Kochis for a quick post about how to make HMAC hashes in Ruby, since the Ruby OpenSSL documentation is kind of lacking at the moment.

If it uses the existing structures, it’s already editable

There’s clearly an incentive to not be so minimalist that you store stuff in weird places. I’ve run into plenty of trouble when people were doing this at work.

But there’s an advantage here, because if I want to add something, all of the various pieces of the framework already converge on the node object.

So I’ve been working out a far-off architectural diagram… or, more precisely, an updated far-off architectural diagram, adjusted for what works and doesn’t so far and how the general Internet has changed. And I keep reminding myself “Oh, if that’s just a page, it’s editable like a page”. And then I have to sit on my thumbs for a few minutes and justify why I’m not stuffing something in the wrong place.

There are four fundamental types of object that the system manages. Nodes, Tags, Blobs, and Log Entries. Each has unique properties — Only Nodes have URLs, for example. But, as I say above, a “Tag” is more than just a flickr tag. A “Log Entry” is also more than you would think.

Thing is, if I have something that can be encompassed within the concept of a page, even if it’s only of marginal utility for it to have a unique URL, it still makes a lot more sense to have it visible where I can find it in the editing tools and where it takes a few lines of code to hook stuff up instead of needing to write a whole new subsystem.