httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: cache: the store_body interface
Date Mon, 30 Oct 2006 20:45:24 GMT
On Mon, 30 Oct 2006 11:36:43 -0700
"Justin Erenkrantz" <justin@erenkrantz.com> wrote:

> > 3) change the interface: deal with the buckets entirely in
> > mod_cache and just pass (char *,size_t) pairs to store_body
> 
> #3 gets my vote.  I hate bucket brigades anyway.  ;-)

-1 to doing that with local, static files.  And once you start
making exceptions to a rule, that becomes BAD complexity.

But as an either/or option (either bucket or buf), that's fine.

> > 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.

What does that 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.

> > 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)

A trivial morphing filter in front of the cache filter would accomplish
that, at the expense once again of forcing morphing even when it
shouldn't be necessary.

> > 4) change the interface: pass some abstract "flush-me" callback in,

Ugh.  Complexity.  Does it gain anything over, say, (1)?

-- 
Nick Kew

Mime
View raw message