httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: cache: the store_body interface
Date Tue, 31 Oct 2006 10:59:49 GMT
On Mon, Oct 30, 2006 at 02:56:24PM -0700, Justin Erenkrantz wrote:
> On 10/30/06, Nick Kew <nick@webthing.com> 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


Mime
View raw message