On Mon, October 30, 2006 8:23 pm, Joe Orton wrote: > 2) keep the interface as-is, but read buckets in mod_cache and partition > the brigade manually; only pass a "small" brigade with known-length > buckets to the provider. (so no morphing and no arbitrary memory > consumption)
Thinking this through again after having a little more sleep. The power of the current brigade interface lies in the fact that a cache provider can, if it chooses to, modify the brigade in such a way as to improve performance. An extremely effective way of doing this is to replace expensive backend buckets with cheap file buckets pointing at the cache file, or in the memory cache case, cheap immortal buckets pointing at the memory cache buffer. This makes it possible to read a response into the cache completely and in the process release potentially expensive resources like proxy connections or CGIs as soon as possible, rather than ages later, when the client is finished the download. Justin has argued that a default cache provider should be conservative in its caching strategy, and this definitely makes sense. But - the cache interface should not enforce a conservative strategy for all caching modules. Should an alternative cache provider want to cache more aggressively, it should be empowered to do so by the interface. The #3 option effectively "dumbs down" the interface, reducing the cache to "store this and don't do anything else", and reduces the scope for better caching methods. My vote therefore goes with #2. Regards, Graham --
