On Mon, October 30, 2006 12:07 pm, Joe Orton wrote: > 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:
So, as has been suggested before, I suggest we have mod_disk_cache that implements the cache as described by Joe here, along with fixes to ensure that it works (it currently doesn't). Then, we have mod_large_disk_cache that does the extra stuff contributed by Niklas Edmundsson. The end user can then make an intelligent choice as to the best cache that fits their needs. > 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 Justin vetoed this. The mod_cache itself should be responsible for breaking any large buckets into bite size chunks, to prevent the cache module from having to care about large responses. This maintains the abstraction between write-to-cache and write-to-network. > 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?) +1 - I suggested mod_large_disk_cache, as it is taylored for large responses, but I'm not attached to any specific name. > Needless to say, code making bogus assumptions about the output > filtering interface has no place in the tree and fails the "correctness" > test. Obviously, thus the notify solution. Regards, Graham --
