On Mon, 30 Oct 2006 01:53:18 +0200 Graham Leggett <[EMAIL PROTECTED]> wrote:
> The current expectation that it be possible to separate completely > the storing of the cached response and the delivery of the content is > broken. Why is that? (references to previous discussion will do, if applicable) > We have a real world case where the cache is expected to process a > many MB or many GB file completely, before sending that same response > to the network. This is too slow, and takes up too much RAM, > resulting in a broken response to the client. That suggests broken or implementation and/or inappropriate usage. It says nothing about expectation. > On wednesday night I wrote a patch that solved the large file > problem, while maintaining the current separation between > write-to-cache and write-to-network as you assert. This mod_cache > code broke up the brigade into bite sized chunks inside mod_cache > before passing it to write-to-cache, then write-to-network, and so on. > > Joe vetoed the patch, saying that it duplicated the natural behaviour > of apr_bucket_read(). > > The wednesday night patch was reverted, and thursday night was spent > instead changing the cache_body() signature to make its own better > judgement on how to handle cached files. > > Now you veto this next patch, saying it breaks the abstraction. All of which says this work is in a state of flux. > I agree with you that a design needs to be found on list first, as I > have wasted enough time going round in circles coming up with > solution after solution nobody is happy with. > > Do we put this to a vote? There are quite a lot of contributors, and there may be competing designs. That sounds like the kind of situation where a single /trunk/ and a single cache framework instance is hopelessly inadequate. If necessary, let it fork, demo your ideas on a branch, then present that for discussion. Isn't that approximately what Paul suggested some time back? -- Nick Kew
