Some stuff.

2005-01-31T13:19:33Z

I've made up a simple, non-database specific schema for the weblogging system. I'd be grateful if you guys could look it over and see if there's anything obvious I'm missing. :) [quick note: stuff in ((double brackets)) are comments, stuff in <> are items that don't actually exist in the table they're in but they do exist elsewhere in the schema, and starred items are the primary/composite keys for the table.]

Here are my thoughts on the system...

The original spec (which I'm using as the spec for this system, so I'll be referencing it quite a lot) says that "Each entry has a title, a category string, contents, time posted (auto-generated), and one or more objects (e.g. images)." It's this whole objects thing that interests me.

So the way I'm thinking of doing it, and the way the schema is designed around, is that rather than the traditional model of an entry having a static text box for its main thing, the entry would - as mentioned above - have the ability to have multiple 'objects'. An object in the sense I'm thinking of would include things like text, images, link lists, and so on. Object types would probably be defined by using XML to allow developers to specify what the object type should consist of, and an additional code file that the system could call when it needs to display the object. This could be distributed and packaged up in an archive format (probably just .zip or .tar.gz, but I'm open to persuasion). When placed in the correct directory on the server, there would be an option in the interface to install it. Doing so would extract the files, enter the XML into the database, and basically set everything up so it can be used.

I'm still at odds as to whether or not I would be using XML for the above, and if I do, whether I store it in the database as plain XML or binary XML. I think the latter question in somewhat academic as developers will only ever use the plain XML - the binary XML would solely be used in the database to speed up processing times. And, of course, binary XML can be converted to plain XML easily enough so it's not going to be a major disaster if the plain XML is lost somehow.

Some other notes on the schema:

Where they appear, "name" refers to the displayed name of whatever it refers to, and "short_name" is a name suitable for use in URLs or internally.

The "short_title" field in tbl_entries is for use in permalinks. Unfortunately this means that it could never be changed from the starting value, which would probably be a bad move. The alternative is to have a table having three fields: internal_entry_id, short_title, and default. That way, it could keep a complete history of the various short_titles used for that entry and automatically redirect the user to the most current one if they used an old permalink. Does this sound like something I should do?

Objects would be able to be displayed either inline or as a separate section on the entry, and this setting would be specific to the entry, not the object. (I'll explain more about what that means in a bit.) When a particular entry's object is marked as being 'inline', I envisage that the object type code for whatever objects are in use on that entry would take that fact and look to see if that particular object has something along the lines of 'object x goes here'. (however that may be for each object.)

Wow, that's confusing. Let me give an example. Let's say you have an entry with three objects - 1 'text' type and 2 'image' types, and the first 'image' object is marked as inline for that entry. So, here's what happens when it's asked to display that entry:
1. The system grabs the entry from the database, along with the references to its objects.
2. The system determines which objects are not marked as inline, and iterates through those objects in the order determined by the 'order' field. Let's say the text has an order of 1, and the second image has an order of 2. (The first image doesn't matter as it's marked inline, so the order is ignored.)
3. The system asks the first object, the 'text' object, to render itself. It passes along the fact that the two images are inline.
4. The system asks the third object, an 'image' object, to render itself. It passes along the fact that the first image is inline.
5. The system, seeing that its job is done, displays all the code.
And bingo, you have an entry where the first image is inline and the second is displayed after the text. I think that's a pretty good way of doing things. The only problem I saw while doing that was that there's no provision for templates in the above. That's obviously going to be important, so maybe internally I should use some sort of native XML that would be automatically converted by the code into whatever template was being used.</li>

So, yeah. Congrats if you managed to get through all this and not have your socks bored off. :D

I really would like feedback on this if people are willing to read it. Thanks!

Reposted from ciaran_h.

2005-01-30T16:25:33Z

Some time ago I found a rather cool proposed spec for the ultimate weblogging system, so I put it in my DeskLinks bookmarks and forgot about it. Just now, I was browsing my bookmarks and saw it again, and I'm seriously considering writing some software that'll implement these points while still being small and tight. Or at least 90% of it, or so.

Yeah, there are others out there - I even have my own journalling software (which is in use in a couple of places - my old journal, and the ODP Weblog), but it only implements four or five of these points, and while the code is indeed small, it's also a little messy in terms of how it works. In my defense, though, it was initially written when I was kind of learning Perl. Since then, it's had one almost total rewrite (which improved the code readability immensely) and another rewrite - though not as major - to implement the templating system.

However, I still see bad things in the code (a minor example being that I set global variables in subroutines... *wince*), and rather than do anything else with this code and try to maintain compatibility and such, it'd be easier (not to mention more fun) to make a new blog system from scratch. That way, I can also put into practice somewhat better coding practices right from the start, as well as aiming towards the goals of the spec above.

So, yeah. This could be fun.

Yay, it's a new journal.

2005-01-30T16:13:03Z

This journal is so that I (soph) can write technical stuff without worrying about anybody dropping off to sleep. :D

Also, unlike my normal journal, this one will be fully public, not friends-only. So no need to reply here if you can't see any other entries, because if you can't see any others that's 'cuz there aren't any. ;)

Ciaran's Tech Journal

Some stuff.

Reposted from ciaran_h.

Yay, it's a new journal.