The glory and stablity of static html

Over the last few weeks my typo install has gotten less stable. The direction of typo is disturbing. It started out as a clean simple blogging system which embodied the less is more elegance of rails. I recommended it to people to see a less toy example of a full working open source rails app. But now it’s become a space for playing with ajax trickery and the code has become smelly and bloated.

This is not to discount the people working on typo, just that it’s going in a direction of a full cms instead of a simple blog publishing system.

Another issue which has been plaguing me is server stability. Tamarin where anarchogeek is hosted wasn’t meant to be a production server, so it doesn’t have 100% uptime. That SHOULD be ok, but the nature of the way rails apps require fastcgi, if there is a problem, the whole app is offline.

That’s not the way it should be. CMS’s should be able to handle having the backend go away and still serve content. This is what we did with the mir project which allows us to serve more than a million page views a day on recycled hardware, home dsl’s, and squatted colo space. Well funded startups like odeo don’t need to do that, but my personal blog or activist sites like indymedia and protest.net do need it.

About six months ago i brought up this idea, that we need to be able to have a static version of the site created out of a rails app. The idea was poopooed. Why do that when you could have caching. Sure with odeo we have memecache doing nifty in memory caching distributed over several servers. But that’s not the kind of thing which is easy to install on a shared host, nor distribute over dozens of donated (loaned) servers where you don’t have root.

Caching doesn’t provide for replication across servers, archiving of the full site, etc… So my question came up, what is the right way to ‘preemptively’ cache the site. To make a static version. One, which i’ve done in past lives, is to write a bot which walks it, saves the html, fixes the internal links, and presents the site as static. Thats the brute force approach.

Another solution, the kind which was used for mir, was to create an xml file which defined every page to be generated by the system. Unfortunately it’s not very DRY, and generally is quite a javaisk type solution. So potentially this could work for a rails based application, but it’s not ideal.

What i’d like to see is a way of saying, these routes are public. These are their associated models. Walk the database requesting and generate the static html pages. It could be a semi-separate daemon. Then we could have a way, like with caching, of requesting new pages be saved / generated when there are updates.

Anyway, i gotta get back to working on other projects…. this has been in the back of my mind for a while. Hopefully i’ll get around to building something at some point.