[this is aaronland] Friday, August 10 2001

Benoit Marchal : Introducing XM, a poor man's content manager

"Many webmasters have turned a combination of scripts (JSP, ASP, or PHP) and a database to help them cope with an ever-growing site. This approach works, but it's not without faults. For one thing, it puts a toll on the server, so the pages may load more slowly. Also script-based Web sites are more prone to bugs or even crashes (of course, I speak for myself; bugs do not afflict your code). Finally, search engines are less likely to index dynamically generated sites. Overall I have found that, while scripts and databases may make life easier for the webmaster, they are far from optimal for the visitor. ... I propose an alternative built on XML and XSLT. Indeed it's easy to prepare documents in DocBook or another XML vocabulary and convert them automatically to HTML. Automatically is the operative word here. The goal is to cut on manual processing and automate as much of the site maintenance as possible. I like to think of it as moving from small-scale to industrial-scale webmastering." Most excellent! via more like this

created

2001-08-10T18:27:09-04:00

last modified

2003-10-11T11:09:00-04:00

revision

1.9

changes

http://www.aaronland.info/weblog/2001/08/10/3264//changes.html

categories

license

http://creativecommons.org/licenses/by-nd-nc/1.0/

external links

[x]

Update : Who mentioned paying 40, 000$ for a CMS?

I'm pretty sure it wasn't me. Are we having the same conversation? If you can live with the tradeoffs that come with whatever piece of software you use for a given task, more power to you. My point is that CMS' are hardly the panacea you seem to painting them to be. Please correct me if I'm wrong, but your argument for the supereme righteousness of CMS' appears to revolve around the idea that a CMS is binary manifestation of some fancy-pants idea that information wants, needs and has to be free. This reminds me of the story Cree elders visiting the vice-president of Hydro Quebec, after the first phase of the James Bay hydro-electric project was built. The rivers around the dams had always contained naturally occurring mercury but it was never a problem because the metal had always sunk to the bottom of the riverbed with all the other sediment. With the constant churning of the waters, though, the mercury was suddenly all over the river and, before long, began to make it's way into the fish. The Cree went to Hydro-Quebec and explained the situation and asked what would be done to rectify the problem. The Cree, afterall, are fishermen. They eat fish. That's how they'd survived for thousands of years. Do you know what the executive in Montreal told them? Don't eat fish. Again, I'm not suggesting that a database backend is a bad thing. They do certain things very well, but it stops there. They are not a cure-all. Manila doesn't have any kinds of privacy/workflow checks and writes it off as information wanting to be free. Blogger forces you to arrange your posts chronologically and writes it off as somehow being truer to the idea of weblog as form. Slash forces you to recompile mod_perl and writes it off as "well, why wouldn't you want to recompile mod_perl?". Greymatter has cleartext passwords and world-writable directories. The code I've written is an ugly nightmare, needs to be rewritten and doesn't let me automagically alias/thread this post back to the original post. In fairness, Zope comes pretty close to being able to do everything. However, it is not especially well-designed for working in tandem with Apache, forces you to worry about backing up/exporting everything out of a single ODB (point of failure) and as soon as you scratch the surface becomes as complicated as fuck. These are all lock-ins. Granted, most --some-- of these problems are dealable and all of the tools mentioned above support, with varying degrees of success, an export functionality so there is always a way out, so to speak. But it all takes time for someone to suss, to integrate, to actually do the work and then to finally fix all the stuff that inevitably breaks. Meanwhile, the bloody Exchange server has crashed again. Further, your whole web-publishing system becomes beholden to a few small people who've had the time to master the intricacies that your CMS tool involves. Sound familiar? My point is that this sort of CMS good, HTML eeeeeeeee-vil talk is misguided and short-sighted. I'm sorry if your IT department is full of goons, but installing a CMS is really only a band-aid solution.