> -----Ursprüngliche Nachricht----- > Von: Joe Orton > Gesendet: Dienstag, 31. Oktober 2006 13:52 > An: [email protected] > Betreff: Re: cache: the store_body interface > > > 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.
That seems to be an important point to me. Although I never used the fd caching of mod_mem_cache this would mean we actually would have to dump this feature. This looks bad to me. Isn't this a showstopper for implementing #3 as new interface? Regards Rüdiger
