jmoiron.net

I've been playing with a few ideas recently, stemming from the perceived inflexibility in my blog software and my inability to develop a gallery over the past, oh, year and a half.

I already know what level of flexibility I want; the wiki. No logging into an admin interface and filling out some convoluted form to create a flat page; you go to the URI you want to represent your text and you add it.

Wiki's can afford this flexibility by sacrificing a lot of what makes a traditional website powerful: structure. When you add data to a wiki page, there is no structure to the text within that page relative to the system. When I add a blog post, there is a strict structure: there is some text that is a "body", "title", "timestamp", etc. This structure is very powerful, because then you can treat all posts the same and provide different views on them. This blog post is rendered by the exact same tiny template as any other blog post in any other url that you find on my site.

But in a traditional "backend" driven website, that structure exists in a relational database. Changing databases is difficult and annoying, and gets moreso as the amount of data you store in them increases. More unfortunately, you have to create that database structure at the beginning of your website development, forcing you to think about the exact structure and interdependence of your data before you have anything off the ground. I've spent 12 months being paralyzed by the daunting task of coming up with all of the possible metadata I might want to save on an image to create photo gallery software.

Some of this is tool failure, some of it is personal failure, some of it might even be my very own ignorance. But there is a kernel of structural failure in the very way that the classic "web application" is created. As it turns out, the "new jersey method" of web content delivery, the completely unstructured wiki, is better for most things.

At its core, at its most deep philosophical level (ignoring community driven content, which is outside the scope of this discussion), a wiki is a way of linking a UID, represented by a URL, to a piece of text. The other step forward in wiki is the pervasive use of simple, human friendly markup.

What if you could apply these to more than just text? What if you could give structure itself an easy, wiki-like markup? A wiki's handling of rich content like images or movies is notoriously bad; what if you applied pythonic namespace theory to a wiki so that /!img/foo.png allowed you to "create" foo.png if it did not exist, or /!mov/bar.flv allowed you to "create" the flash video bar.flv at that "location"?

I've been mulling over this recently, and over my own dissatisfaction with django/turbogears/pylons and just SQL in general. I've had some interesting ideas for wiki extension (like pervasive use of DAV, using an RCS backend instead of a FS backend, etc), and looking into "thin" web glue technologies like paste to assist in creating a framework suitable to my needs using mod_wsgi, django's URL routing, CouchDB as a backing store and whatever templating language I end up preferring (probably the fastest one).