On 10/30/06, Joe Orton <[EMAIL PROTECTED]> 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
