There may be a simpler approach, less clever but perhaps faster to implement. Have objects give ZServer a "time to live" value, which is set as a property on the object, but whose value is associated in the cache with the request URL. So if objects foo and bar have dtml method baz, and baz has a time-to-live of say 5 minutes, then the results of calling /foo/baz and /bar/baz should each be cached for a maximum of 5 minutes from the call. This value could be acquired, allowing the source object (or its class) to set it. While not perfect, this could do quite well for a lot of applications - especially of the portal/squishdot variety. At 05:39 PM 6/10/99 +0000, Jim Fulton 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.)