While Eberhard states that dynamic page creation - which seems to be the vouge nowadays - has major performance drawbacks, I would like to outline a process that marries bothe concepts in a way that could take 'the best of both worlds'.
The main ingredient here is what one could call a 'cached-interpreter'. Using a run-of-the-mill dynamic page creation process (be it PHP, Zope or anything) and putting a simple process in front of that. This 'cacher' would handle the actuall request from the client:
A very simple setup of this kind could (and will) be built with PHP and the apache 'error-document' directives. These enable the webmaster to specify a custom 'page' to be shown in case of tzhe 404 file not found (or other) errors. The URLs in the website would now all point to static URLs (ending in .html). In the case of one of these URLs not existing, the 404-handler would be called. Apache passes the originally requested URI along, so the 'error-document' can now be the 'cacher' described above. The 'cacher' will now take the URI it was passed, modify it slightly and query the dynamic page creator withe that (this can be as simple as changing the .html suffix into .php). If the creator returns a page, this will then be streamed to the client and a correctly named static version will be written to disk. The user (client) would only have latencies in case the caching process would need to be fired, so only on the first request. 're-building' the static content could in this szenario be initialized by manually deleting some or all static cintent (cache)
One could also call this approach 'compile on demand'. It would also effectively kill those annoying re-build times tools like Radio or MoveableType have. Static content would only be generated 'on-demand'.
[Afterword:] the funny thing is, the basis for these ideas where layed some time ago in a discussion I had with Eberhard, Chris and Andi in the gone-but-not-forgotten Lcom Groove-Space.
similar entries (vs):
similar entries (cg):