To this I agree, but there is technical reasons making it not that suitable to do within Squid.
What is a viable approach is to add a second database for this purpose in parallell to Squid, keeping track of the URLs in the cache. This database can be built automatically by tracking the store.log log file and feeding the data into a database of choice. For tracking the store.log file the per File::Tail module is very suitable, but some database design is probably needed to get a database which can be searched in interesting ways.
I wrote a perl utility to do this for a client about a year ago. It records to an SQLite database and works fine for what it does.
However, we ended up using a different method of maintaining their cache (we triggered purges on site object update, rather than purging subdirectories), and so the development was never finished. It will need work to be useful, and I simply don't have time to look at it at the moment--but I'll be happy to forward it to anyone who wants to work on it. (Really, believe me when I say you will have to code to make it useful for you. But the database maintenence code is complete and reliable.)
It is my opinion that the 'slow' purge tool you have referenced is more useful for general use.
--
Joe Cooper <[EMAIL PROTECTED]>
Web caching appliances and support.
http://www.swelltech.com
