On Mon, Oct 30, 2006 at 02:56:24PM -0700, Justin Erenkrantz wrote: > On 10/30/06, Nick Kew <[EMAIL PROTECTED]> wrote: > >What does that [#1] break? > > > >Seems an easy/low-level solution. Does the provider return a > >status value to say "I have/haven't passed this stuff down the > >chain"? It has the feel of something that pulls down the level > >of abstraction: not sure what that loses. > > With #1, you don't have any knowledge as to when the filter died or > how it died - was it the cache storage that died? Or was it the > client? Who knows. So, it makes recovering from storage failures > very problematic or you put a set of 'hidden' constraints on the > storage functions to try to encourage recovery - but I'd rather make > such things explicit. -- justin
I very much sympathise with this argument. But it does mean that the storage provider cannot break any of the assumptions mentioned in the other thread: it enforces the synchronous store-to-disk and write-to-client model. I think it's a reasonable desire to ship a non-default storage provider which implements the "stop and write entire response to disk before sending anything to the client" model. But #1 prevents that; such tricks could only be done somehow at mod_cache level, or only by entirely replacing the cache. joe
