Wiki Migration Notes - Platform Selection

These notes are obsolete. Most of the relevant ones were incorporated into Yaki.

There are several aspects concerning platform selection that I've been thinking about:

Disregarding hosting for the moment, the site has relatively modest hardware requirements, and I would like to downgrade them even further. The hardware where I initially deployed it (until mid-May 2005) was a PIII 733MHz with 1GB of RAM, sporting a loadaverage in the low tenths (i.e., 0.11 to 0.2). This was largely due not only to the extremely efficient LAMP setup, but also to Turck mmCache, which speeds up PhpWiki to the point where page build times are less than one-hundredth of the page transfer time.

Current hardware specs much better (and likely to change again soon), but the site's growing popularity is yet another driver for it being as efficient as possible.

The site currently runs on a somewhat tweaked Fedora Core box, but before accepting Melo's kind offer I had been considering moving from the heavily customized RedHat 9 setup I had to a barebones BSD (or even Darwin) setup to make the most of the hardware and make sure I unlearned some of my Linux vices (it's not bad, it's just not the only thing out there).

Had I taken that route, package management would be somewhat of an issue, but I (unlike most modern-day UNIX guru wannabees) have long valued stability over bleeding-edge, and the site itself has suffered very few upgrades over the years (mostly my custom PHP builds and the odd Apache patch).

This is the tough one. PHP is blisteringly fast for this, is closely tied to Apache and has oodles of support for XML, Flash and other niceties. It also helps me maintain the site with nothing more than SSH and vim, providing instant gratification. PHP5 also promises faster (and cleaner) code and a few new doodads, so it's tempting to keep using it.

However, it's not the only option. Python (and Twisted) has been proving quite interesting lately (although I still won't touch Zope with a yardstick), and despite some performance concerns (yes, I think it's slower than PHP for this sort of thing), I like the clean, unencumbered coding style and the ready availability of lots of XML functionality.

The thought of replacing Apache itself with a Twisted server has a lot of appeal, too, because I would have a lot more control over HTTP transactions. But Python has a tendency to deprecate basic libraries across releases, and, in the whole, feels a bit out of control.

Perl is not an option - not because of lack of power, flexibility and performance, but essentially because I do not code like a pack of squirrels on crack, and hate filling myself to the brim with caffeine to be able to read some of the code out there. CPAN can also be a tremendous hindrance sometimes, making it tough to understand exactly what packages you are running (I've been bitten by sub-dependencies changing their APIs, and let me tell you it's an incredibly tough thing to figure out).

Ruby on Rails has popped up on my radar now and then (and I have used it to good effect), but it is evolving too fast to keep up with right now, and feels altogether too much like reinventing the wheel with trendier hubcaps. Fine for standard DB-oriented apps, but not really quite all there yet, even with its amazing JavaScript-based eyecandy.

Java is not an option, either, because I don't fancy indulging Tomcat's every whim and, despite not having any real speed issues with it, I don't like the humungous waste of system resources that I've come to associate with it.

Wiki Package

Hmmm. Very tough one, and closely tied to the language issue. So far, I haven't found a single Python Wiki I like the insides of, for instance. But there are other things:

Storage Backend

I like mySQL well enough, but it's a waste of resources - SQLite would work just fine and have a smaller footprint. Still, I'd really like a filesystem-based Wiki store, with only a few cache files to maintain node relationships and all of the base markup (plus images) stored as individual files. CVS springs to mind, but hosting forces me to consider rolling my own versioning and storage scheme.

Markup

I'm strongly leaning towards using Textile as markup instead of the standard PhpWiki markup. It would take some getting used to, but it's ultimately better for writing longer documents and looks easier to convert.

Rendering

Anything I move to will have to render the markup using XSLT - it's not just the way forward, it's the sensible way to ensure my data is readable a decade from now. It is, however, a terrible mess at this point, and almost completely against my lower hardware requirements goal.