On Mon, Jul 14, 2003 at 01:01:50PM -0700, rbb@rkbloom.net wrote:
> On Mon, 14 Jul 2003, Justin Erenkrantz wrote:
>...
> > The correct solution, IMHO, is to have mod_dav pass flush buckets down the
> > output chain by using ap_rflush or sending down its own flush buckets via
> > ap_filter_flush. The function that looks like it definitely needs the
> > flush is dav_send_one_response. Not sure if that'll catch all of your
> > cases or not - it may need to be added other places.
> >
> > mod_dav knows when it is appropriate to flush the content. mod_deflate
> > doesn't attempt to make any determiniations on its own when to flush.
> > Mainly because doing the flush may be expensive in zlib - we don't want to
> > do it on every deflate() call. That logic is best placed in the handler -
> > mod_dav. And, for the most part, mod_dav does create flush buckets - it
> > just seems to be missing a few obvious cases. -- justin
>
> Sorry Justin, but that is bogus. The whole point of the handler/filter
> flow is that the handler shouldn't have to control stuff like this. The
> filter needs to realize that it has buffered far too much data and flush
> it appropriately. Take a look at the core_output_filter. It doesn't wait
> for a FLUSH bucket from the handler. It notices that it has buffered 8k
> of data and takes the initaitive to get it to the network ASAP. If you
> push this up to the handler then every handler will need special logic to
> deal with every filter.
*giggle*
"I agree whole-heartedly with Ryan here"
*snicker*
What Ryan said. The handler shouldn't ever say "force this to the network".
Cheers,
-g
p.s. for the curious... Ryan and I (historically) didn't see eye-to-eye
often... hehe...
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 08:49:27 2003