At 05:39 PM 6/10/99 +0000, you wrote:
To take these musings a step further. I can imagine a mechanism by which:
- Certain objects could inform ZServer of object IDs of the objects that constitute thier "source" data,
- Zserver registers with the database to be notified when objects change (by object ID),
This could allow ZServer to do some clever caching even for some relatively dynamic objects.
(Note that figuring out what the "source" objects for an object are could be pretty tricky. While some objects, like Images, Files, and most DTMLDocuments are their own source, other objects, like DTMLMethods might depend on thousands of objects.)
Caching in Zope is an interesting, though complex issue. Clearly some object always return the same or similar content, but many more return the same content most of the time, but not all the time. The rest are totally unpredictable ;-) In any event, I'm happy to see Jim yield a little on the idea of caching. I think caching could considerably improve Zope performance for heavily trafficked, non-dynamic sites. I would like to add that the response generated by some objects depend on the user. So for example we wouldn't want to cache DTML Methods which display different data depending on the roles of the user who accessed the page. OK, maybe this can be abstracted to say that caching could be tied to request environment variables, such as "AUTHENTICATED_USER", and "PATH_INFO". Presumably caching info would be communicated to ZServer via HTTP headers... Another issue is being able to write a cache to the filesystem so that other things besides ZServer will be able to serve up cached items. Hmm. Interesting stuff, but who's got time to implement it ;-) -Amos