Saturday, January 3, 2009
The core idea originated in an internal perfectionist tirade I had while building a simplistic content-publishing site in LAMP. The modus operandi for LAMP is that your content is stored in a database, and a script fits that content every time it is requested into HTML.
The database model has won the day because it is very flexible and supports a model that is pretty easy to understand, but it's always nagged at me that, especially for a site that publishes high volumes of content, code on the web server is constantly issuing queries (as opposed to just quickly navigating a file tree), fetching the pieces of content, and custom-assembling what is almost always the same exact content for every visitor. Bigger players in this space often use caching—essentially, inserting yet another server between publisher and reader that keeps a copy of this custom-assembled page to serve up to multiple people instead of having the backend server do it again for every request.
When I first discovered markup languages like HTML I was very intrigued by them. They (at least when used properly) don't just pretty things up, but they also impose a structure for a document. What's so great about that structure, though, is that it means that if you construct your document carefully, you can read it back again and deconstruct it into its component pieces (i.e. title, publication date, author, text). If a web publishing platform took this into account, it could circumvent the whole process of assembling the same servable content for each visitor and still retain the flexibility, permitting each document to be changed simply by reading it in, changing what needed changing, and writing it back out again.
There's one other piece to the puzzle that makes my platform complete, though. Despite all this tirade about inefficiencies in web publishing, I am actually a great fan of what is possibly the most inefficient platform of all, Zope. The reason for this is the model by which I interact with it; instead of dealing with rows in databases or opaque files on disk, I instead deal with Python objects, whose classes can encapsulate all kinds of behavior. I determined that if I take the read-in/change/write-out bit named above and apply it to object persistence, I can now insert the power and ease-of-use of object-orientation into this very efficient platform. It's kind of heady, honestly.
I call the whole thing "teaspoon", which is a bit of a geeky play on words; round-tripping a flat-file form to objects and back is called persistence, and I'm parsing HTML as "tag soup"; giving me the concept of "tag-soup persistence". The Python module for this is called tsp, which is also the common abbreviation of the good old teaspoon measurement that I still use cooking today... and so I have my sufficiently Web 2.0 name ready to go.
Until I do get this project off the ground in a real way, I continue to use Blogger to write, and while Blogger's feature of publishing HTML pages that don't require rejiggering for every visitor is a step in the right direction, it's not fully bidirectional like teaspoon would be.
So, I press on.
Further comments are disabled indefinitely. Here's why.