Justifying Dauxite

May 6, 2004

<< XSLT considered harmful

In between my day job, freelance work, art-world paperwork, Lafcadio maintenance, and karaoke, the first pass at Dauxite took about 3 months to code. It's about 6000 lines, and it's not done by a long shot, but it's to the point where I can stop thinking about it for a while. (Knock on wood.)

It has some intriguing ideas in it, but if it were expanded to a more demanding site it would need a lot more work. For one thing, it's slow as molasses: Render times on most pages can be measured in seconds. Off the top of my head I suspect that this is because all those content filters duplicate effort to parse and unparse XML, which suggests some good avenues of optimization, but of course it's quite possible that Dauxite's design is just inherently slower than other approaches.

A bigger problem is that Dauxite does not support forms or user interactivity. Model-View-Controller is a lot simpler if you leave out the Controller. I'm not certain how Dauxite would handle a highly dynamic page that contained database-driven content, forms, and designer-configurable text, though I may eventually give it a try.

One thing to note is that having all these content filters promiscuously passing XML among themselves sounds a lot like web services, only without the web. So what would happen if you added the web? Would it ever make sense to have content filters living on different servers?

And what about that site.xml file? If I made that a public resource to be consumed by others, it could be useful. Mostly it just mirrors the site, but it would offer a much clearer way to see some of the site's structure. For example, generating a site map would be easy. (The content hierarchy is not the same thing as the file system hierarchy.) Is that the sort of thing people would ever want to do to other people's websites? Maybe I need to write some sort of standard first ...

<< XSLT considered harmful