Hi Steven, There are some good ideas in your mail.
May you open corresponding issues on JIRA (one issue for each point) ? Regards, 2007/10/10, Steven Brown <[EMAIL PROTECTED]>: > I would like to put up a few Zend_Cache changes for discussion: > > 1. Zend_Cache_Frontend_Class should not require cachedEntity in the options, > instead you would be able to pass either a class name or object to a "call" > method just like Zend_Cache_Frontend_Function. I understand the current > setup is a bit cooler in that you can simply call the method directly on the > cache object, however I feel this is not flexible in allowing me to use the > same cache object for methods of multiple classes or objects. > > 2. Zend_Cache_Frontend_File should not require a unique ID, it should be > automatically generated from the path and filename in the same way some of > the other frontends are able to automatically generate IDs. > > 3. In Zend/Cache/Backend there is a file called Test.php, is this supposed > to be there? > > 4. It would be good to be able to allow cache "atrophy". There are two > different forms of atrophy that could be available based on data changes: > > a) A minimum and maximum cache expiry are set (say 5 mins, 30 mins), > at first the expiry is at the minimum (5 mins), if the data has not changed > at the end of the expiry period, the expiry period then increases by > the atrophy rate (say 20%) so it is then longer (6 mins). This continues > until the maximum expiry period. If the data has changed at an > expiry point, the expiry period is reset to the minimum (5 mins) or possibly > decreases and the process starts again. This attempts to spend less time > refreshing cache that does not change often. > > b) A minimum and maximum cache expiry are set (say 5 mins, 30 mins), > at first the expiry is at the maximum (30mins), if the data has changed at > the end of the expiry period, the expiry period then decreases by the > atrophy rate (say 20%) so it is then shorter (24 mins). This continues until > the minimum expiry period. If the data has not changed at an expiry point, > the expiry period is reset to the maxmimum (30 mins) or possibly increases > and the process starts again. This attempts to keep changing data > fresher. > > There is also another approach based on traffic: > > c) Minimum and maximum expiries are set as above, along with traffic > levels and an atrophy level. As an item becomes more and more popular the > cache expiry gets shorter and shorter to ensure the data is as > up-to-date as possible. > > d) Same as "c" except the cache expiry is set longer and longer as > the item gets more popular. This means the load is being reduced by caching > more and more when items are popular, however they become more and > more out-of-date. > > Any feedback on these concepts would be much appreciated. > > Cheers, > Steven > > > -- Fabien MARTY [EMAIL PROTECTED]
