On Tue, Oct 31, 2006 at 10:59:49AM +0000, Joe Orton wrote: > 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 meant to also mention (sorry for all the mail): it prevents mod_mem_cache's fd caching trick too, which relies on being passed FILE buckets. joe
