Thanks Roy. So, the goals for mod_disk_cache as I see it: A simple general-purpose disk cache which makes no assumptions about speed of backend, speed of storage or speed of clients; is single-threaded and does not involve any multi-process synchronisation beyond open/O_EXCL. Specifically:
1) cannot write entire response to disk for any content type before sending anything to the client; filter acts by writing to cache and client synchronously 2) avoids writing a given URL/variant to the cache more than once simultaneously using open/O_EXCL 3) for the case where multiple simultaneous requests are made for an uncached but cacheable entity, will simply pass-through all requests for which the open/O_EXCL fails and does not attempt to read from an as-yet-incomplete cache file A disk cache which makes different assumptions about speed of backend or uses more complex caching tricks should be in the tree as a different provider in a module with a different name; the exact assumptions made need to be well documented. (Maybe something like "mod_local_disk_cache" would be appropriate for the name?) Needless to say, code making bogus assumptions about the output filtering interface has no place in the tree and fails the "correctness" test. Regards, joe
