Home Geschichten Kunst Computer Tindertraum


Content creation (compilers vs. interpreters)
(Thursday 1st August 2002)

As always whenever Eberhard posts a new thought-theme-page-entry, he provoces multiple responses in my mind. He splits page (content) creation strategies into two main camps:
- systems that take some descriptions (templates) and some content and produce complete pages that will then be served as static pages on the server.
- systems that do the above for each and every page request. This is what typically is called 'dynamic page creation'
Obviously static content has one major drawback by nature. It is static, and won't do very much good in an application context.

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:

  1. check if for the requested URI a cached file exists, and test the validity of that according to certain rules (time, parameters etc.)
  2. if the cahe was valid, simply stream the content of that to the client, maybe optionally filtering it (session IDs etc.)
  3. in case the cache is not valid, call into the dynamic page-creator
    1. return the result of that call to the client
    2. and write this sane result to disk as new cache-file

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.

[ by Martin>] [permalink] [similar entries]

similar entries (vs):

similar entries (cg):

relevant words

Martin Spernau
© 1994-2003

traumwind icon Big things to come (TM) 30th Dez 2002

Only one element of each kind
Oblique Strategies, Ed.3 Brian Eno and Peter Schmidt

amazon.de Wunschliste


usefull links:
Google Graph browser
Traumwind 6-Colormatch
UAV News

powered by SBELT