Oh boy. The WordPress 2.0.5 update came out, and my hosting provider (DreamHost) offered an auto-update from the then installed 2.0.4 version. The prior updates were only slightly bumpy, but this time Something Broke.

Was the fault in WordPress, DreamHost, or mine? Cannot muster any enthusiasm for debugging someone else’s server-side PHP code (yuck). Since programming is my day job, this is not my idea of “fun”.

Ever had one of those times when a number of incomplete slightly-related notions seem to come together? Maybe it was an after-effect of the cheap Halloween candy I consumed after the trick-or-treaters stopped. In any case, found I could not sleep and a common thread seemed to emerge from a cloud of somewhat-related questions and notions.

  • Good distributed system design pushes compute load where practical to the clients. Web-browsers with their built-in HTML parsers, Javascript interpreters, and mostly-idle CPUs should be used over server-side code where possible.
  • Web sites, wikis, and weblogs access is overwhelmingly reads, with few writes. Seems if you are going to build HTML on the server, you want to do this once on write. Read access from a static file would be exactly optimal. Taken together, you want to generate the page HTML on write, and save as a static file.
  • Recent work has allowed me to become comfortable with using in-page Javascript to fetch JSON data and HTML fragments from the server, and incorporate into the client-side web page.
  • Server-side HTML generation (like ASP/JSP/PHP pages) has always felt wrong to me. Need a better alternative.
  • Seems that the notion of a wiki and a weblog should not be distinct.
  • Standard web servers are hideously efficient at serving static files. Seems we should take advantage of this - and other built-in behaviors.
  • One of my father’s neighbors has a small business (related to solar home construction). Their website is typically lame. I could help them do better, but a collection of static HTML pages gets unwieldy fast. Could adapt WordPress, but that would require continuing support on my part to keep them running - not sure I want to be on the hook. Could adapt one of the existing open-source CMS implementations - but last time I looked they all sucked in one way or another.
  • The company I work for is in the process of updating the company website in a big way, and things are not going as well as they could. The outside consulting outfit that did the initial work … as far as I can tell, their work sucks. (Lots and lots of companies run into the same exact problem.) Seems there should be a better way…
  • Wikis, weblogs, and company websites should allow efficient indexing by search engines. At the same time, when there are multiple views on the same data, you probably only want the search engines to index one. Pages composed dynamically on the client-side are unlikely to fare well with search engines. For example, in the case of a weblog you do not really want search engines returning hits on composite views (all articles on one date, or under a category or tag).
  • When editing the presentation of an HTML page, I really want to use best-of-breed tools (like TopStyle). Directly viewable plain-HTML templates seem best. Editing mashed up combinations HTML and some server-side programming language is a pain (as in PHP/ASP/JSP) if you care about presentation.
  • Someone spent the time to do a decent client-side wiki-markup to HTML bi-directional converter (very cool).
  • Someone else spent the time to build decent client-side in-page text editors (of which there is more than one of interest).
  • There are various server-side templating system, none of which I have found inspiring. Why parse HTML on the server when there are already perfectly serviceable HTML parsers in the web-browser?

Update: Found the problem. Running PHP via FastCGI and stock WordPress yields the following errors in the Apache error.log:

FastCGI: comm with server "/home/dreadedhill/bannister.us/php5-wrapper.fcgi" aborted: error parsing headers: duplicate header 'Status'

Right … I’d found this when turning on FastCGI with an earlier version of WordPress. Found an article in the DreamHost Wiki with the fix.