Description: ------------ Currently, the cache system keeps cached data for a given amount of time. I'm writing an application for which I cache some compressed version of files. I want to always keep the cached file (or maybe for a very large amount of time like 10 days), unless the real file doesn't exist anymore. My proposal is to externalize the condition by using a callback, or an interface. The signature could be function condition($id, $group, $cache_filename) or something like that.

Are you sure the the "$doNotTestCacheValidity" option is not the solution of your problem : http://pear.php.net/manual/en/package.caching.cache-lite.cache-lite.get.php

I don't think so... My goal is not to retrieve data even if it's too old (did I get right what $doNotTestCacheValidity does?), but to remove some of the cached data when I clean the cache (the data that are no longer associated to real files, because the file has been deleted).

Ok, now, I understand your problem. Your idea is to modify the clean() method or the get() method ?

I had a little look at the code. It looks like my idea would require you to change lines 545 => 564 (in the _cleanDir function): instead of the switch $mode, you could call a method on an object (something like $mode->isValid($file2), with $mode set by default to some old, notingroup or ingroup object). You may want to do some benchmarks, but I'm confident that calling an object method will be as fast if not faster than switching over a string...

I'm searching a good way to introduce your idea without breaking API compatibility. Ideas (and code) are welcome

Implement 3 different small object that use the same interface, one for each current mode (you would have one class for old, one for ingroup, one for notingroup). Now in clean function, you must allow to pass a string ('old', 'ingroup', 'notingroup') or an object (that implements the interface). So just do something like if (is_string($mode)) $mode = new "Cache_Lite_Mode_$mode"(); In _cleandir, replace the switch($mode) with if(!$mode->isValid($file2)) unlink($file2); After that, I can create my own Cache_Lite_Mode object that says an object is invalid when (whatever you want here) and call $cache->clean(false, new MyValidityCondition());

hum... I don't like the idea to introduce new classes in Cache_Lite. I prefer a KISS idea : My proposal : - just introduce a new sting mode "callback_myFunction" - in this case, the function (not method) myFunction would be called with the complete cache file path in args - the function would return a boolean to answer the question "do I clean this cache file ?" Of cause, if the mode is "callback_foo", the function foo() will be called. What do you think about this idea ?

Hum... I think it will be less powerfull than with the class thing (but that's probably because I'm an OO addicted person), but it will be flexible enough for what I want.

I have commited it to the CVS. You have to define a foo() function returning a boolean (true => the cache must be cleaned). Arguments are the complete path of the cache and the cache group. Then you can call the clean() method with somethink like this : $cache->clean('cacheGroup', 'callback_foo'); Now, I'm waiting for your feedback with the CVS version for releasing a beta release.

I'm just thinking about something I didn't think before... There is no way to retrieve the id that is used for the cached data from the filename (assuming fileNameProtection is set to true)?

no because the protection is a md5() hash

the feature is the new 1.5.0 beta release

Don't know if I should start another Feature request... But I would like to have a way to retrieve the id from the filename, at least when fileNameProtection is turned off. This would allow a better control on the caching condition (since only the filename is passed to the callback function)

- with fileNameProtection set to "on", it's impossible (because it's impossible to inverse a md5() hash) - without fileNameNameProtection, it's stupid easy becase the file name is choosen with this convention : cache_$id_$group

Thanks... I'll rely on that. Since it's not written anywhere in the end user doc (or I missed it), I was just worried if it was subject to change in future releases.

I understand your point of view but I want to limit the number of methods in the Cache_Lite core class. I have no project to change the cache file naming convention in the 1.X.Y branch. So I think that you can rely on this.

Thank you for this usefull feature (at least it's usefull for me). It seems to work very well.

:-)