A lot can be said about the quality of Wikis and other purportedly collaborative projects without moderation, an "artistic director." Nevertheless, they do provide a useful tool for sharing information. Infact, I'd like to integrate Ion's Web page into a Wiki, with the essential pages moderated, however. There's just a small problem: the Web interface. Sure, the Web interface is essential for those occasional edits by random contributors. But for the frequent editor, the tiny and volatile box with poor editing capabilities in the browser becomes a major hindrance, not to even mention big batch changes. Unfortunately, few Wikis and other simple content management systems provide a safe and simple way to access the data with standard Unix tools.

Blogging tools have exactly the same problem. The vast majority of these tools only offer a Web interface, which makes posting longer stories cumbersome (pasting is cumbersome too), and demands typing in passwords, and other annoying stuff. Now, there are a few command line blogging tools: nanoblogger, which I'm using, and (Py)Blosxom. Unfortunately, these tools are in many other ways far inferior to their Webapp cousins. Nanoblogger, for one, is very slow, difficult to upgrade, and comment support is too kludgy to use. (Py)Blosxom, first of all, are located at ugly CGI URLs, and on the other hand, use too restricting hierachical categorisation, and take article dates from the file system. But that's the date of creation or modification of that particular file, not necessarily of the article itself! Of course, it would also sometimes be useful to be able to use a Web interface, even if you normally don't use it. Not having to use HTML directly would be nice as well, and that applies to nanoblogger too.

So, we see that a degree of user interface monoculture reigns in the area of Web applications as well. In both of the above cases, Wikis and blogs, or content management in general, there's so obvious a solution to this problem with many other benefits as well, that its avoidance can only be a case of the NIH syndrome. The approach is to use a proper version control system for data storage. This way the Wiki or blog software doesn't have to specifically provide non-Web access to the data, and yet it can be done in a safe and version-managed manner. The Web application software simply becomes an engine to convert articles in a given nicer format in the version control system, into HTML pages, and a Web interface to the version control system that supports editing. Possibly some additional caching is needed on bigger sites.

Moreover, if flat-file storage is used, there's a plethora of possible version control systems to use, offering various tradeoffs in features and performance, such as Darcs[*], Bazaar-NG and Mercurial. Given the flat file access, the extra code to support an additional version control system in the Web interface should be minimal. Infact, a flat file version control system could easily be used for pushing data to a (Py)Blosxom site, as the articles live in a separate tree. Unfortunately that still won't rid them of their other problems. For a system insisting on a separate database, there's SVN. (I don't know if any benefits of SQL databases are lost with it or a decent organisation of flat files, if there even are any.)

So, please stop reinventing the wheel, and use a proper version control system for data storage in your Web applications. That way your application automatically provide a safe non-Web interface without any (significant) extra effort.

###

[*] Darcs being my favourite in particular due to the excellent cherry picking features its more advanced (and thus slower) algorithms provide. Now that Bazaar-NG and Mercurial offer most other features of Darcs with almost the same simple interface, I may, however, eventually abandon it due to 1) the anglophone reluctance to support locales and store metadata in UTF-8, instead expecting the user to take care of incompatible encodings, and to 2) display dates in ISO-8601 style formats instead of the illogically ordered and unreadable anglophone format.

Update: As has been pointed out by a few members of the audience, there is a new Wiki and blog project in early stakes, ikiwiki, that pretty much follows the principles laid out in this article. Hopefully it will grow into an excellent content management tool.