revjim.net

My initial thoughts for InkLog could be summarized in a few simple statements. Everything is a node. All nodes are displayed through templates.

The underlying theory is also simple. What makes a "blog" a "blog" isn't really anything other than a date sorted collection of data. So, the theory behind InkLog was to make everything within a website detectable and sortable by date.

There are already thousands of applications to upload text files and give them a pretty look and feel. And there are thousands of applications that allow one to upload images and put captions on them. But I wanted InkLog to be able to track ALL changes to a website (or even multiple websites) and then, display those changes to the user. Of course, in addition to this, the existing features of these systems need to be duplicated.

The easiest, fastest, cleanest way that I could see to do this, was to store EVERYTHING in a site, in the same fashion. With this in place, one simple database query would be enough to gather any information anyone could ever need. All of the articles, forms, journal entries, weblog entries, images, polls, quizzes and static pages in an entire site would be regarded the same. These items would be stored with a few pieces of information attached to them: date, category/path, file type, metadata. Once it was decided which pieces of information should be displayed, the system would nearly need to call an output function based on the type of each item in order to display it properly.

However, the more I think about it, the more difficult it becomes. Let's say, for instance, that I want to add an RSS Reader to mix. Okay, that's simple enough. We'll create a new object type called "rss feed" and the data of which will be equal to serialized PHP data representing the items in the feed. If a new item is detected, the date on that item will be updated to the current time, thus making that feed appear to be updated. At regular intervals, via cron, the system can look for all items of type "rss feed" retrieve newer versions of that feed and update the item accordingly. Like I said… that's pretty simple. Or is it?

Let's say I have 10 feeds added into a category/path named "friendslist". Examining the systems nodes is fairly simple. Determining which node was recently updated is fairly simple. Creating a view of that node that will display all of the items in that feed is simple. However, in order for the application to function as I believe it should, each item INSIDE the feed should show as an update of its own. I don't want to know which feed was updated last, I want to know the details of the actual update that was made in the order in which it was made. Now, this can be done by having the cron job actually add (and delete) nodes from the system as it sees new items. It can even use feed information to help categorize the items into more usable subsets. It's certainly doable, it's just a lot more complicated.

It still seems like the right way to go. It seems like this method would make the most sense. In the long run, I'm emulating what the webserver does (statically) already. Only, in this case, everything is templatable, file types can be converted from one to the another on the fly, the data is in a database and is automatically searchable and sortable.

I really wish I had another head around here that I could bounce ideas off of.