Martijn Pieters wrote:
Why would you want the cache to be persistent? The data is already elsewhere in the ZODB, and the usual behaviour of a cache is to not persist over reboots.
1. Expensive methods - one use for the zcache is storing expensive methods' results without having to run them every time you need their info. 2. Lets say you want an article that changes once an hour (or the output of fortune, like Slashdot has). Write a method that outputs the next article in the list of possible articles every time it's run, and the have a zcache point at this method with a expiration rate of 1 hour. Now your article gets updated every hour, assuming its being read - if no-one reads it, it isn't updated, so you don't waste content, and you don't have to worry about cron jobs. I might add an alternative expiration method, maybe similar to the cron syntax, so you can have it expire at a certain hour. For example, expire cache contents at midnight every day would update your article once a day, as opposed to current method which limits you stuff like expiring if 24 hours have passed since the last access. On an unrelated note, writing the contents of the ZCache to file instead of using the ZODB has the benefit that I can use the same method Apache uses for generating Etag headers - inode together with last-modified date. (Etag headers are used by HTTP proxies as a unique identifier for your page so that they can check when the content on the web server has changed.) So I'll probably end up using files loaded by __setstate__ into volatile variables. -- Itamar S.T. itamars@ibm.net