On Mon, 30 Oct 2006 11:36:43 -0700 "Justin Erenkrantz" <[EMAIL PROTECTED]> 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
