httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Erenkrantz" <jus...@erenkrantz.com>
Subject Re: cache: the store_body interface
Date Mon, 30 Oct 2006 18:36:43 GMT
On 10/30/06, Joe Orton <jorton@redhat.com> wrote:
> 1) change the store_body interface to allow the storage provider direct
> access to f->next, so it can flush buckets up the output filter chain
> when they have been stored.  As seen on trunk.
>
> 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)
>
> 3) change the interface: deal with the buckets entirely in mod_cache and
> just pass (char *,size_t) pairs to store_body
>
> 4) change the interface: pass some abstract "flush-me" callback in,
> which the provider can call to pass up then delete the bucket.
> (apr_brigade_flush doesn't quite fit the bill unfortunately)
>
> IMO:
>
> if you're going to be reading buckets from the brigade in mod_cache, you
> might as well go the whole hog and do (3), and stop exposing the
> provider to buckets or brigades at all.  This will prevent the provider
> from doing any particular optimisations based on content type (like
> copying FILE buckets); feature or bug, take your pick.

#3 gets my vote.  I hate bucket brigades anyway.  ;-)

The problem with #1 is that the failure case gets too goofy as it'd be
hard to recover from failure (what I labeled as #5 in our list of
principles).  -- justin

Mime
View raw message