httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <stodd...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Mon, 02 Oct 2000 15:07:47 GMT
> > Actually, I think I will upgrade this objection to a veto for two
> > reasons:
>
> I'll double that veto, but with some different comments.
>
> > 1. It is easy to write a buffering filter without unnecessary copies
> > using the setaside facility, i.e. only TRANSIENT buckets would get
> > copied. What has been committed copies far too much unnecessarily,
> > and fails to allow for 3rd party bucket types.
>
> While this is true, Bill is also right.  Avoiding copying is a laudable
> goal, but it is just a goal.  It should not be the end all be all of our
> filtering.  There are times that copying is a good idea, and it is the
> correct design.
>
> The problem is that we need to be very careful how often we copy, and when
> we decide to copy.  I think 99% of this problem can be solved by putting
> some buffering in the ap_r* functions and by converting all of the current
> handlers to use the buckets directly.

Introducing buffering in ap_r* function is a good possibility. Need to give it
more thought. Still not convinced how using buckets directly in the handlers is
good. mod_autoindex works now. We have a couple of reasonable (I think) options
to fix the 2000 iovec problem (buffer filter or buffer ap_r* functions).  I just
don't see the benefits of reimplementing mod_autoindex directly in buckets. It
will introduce bugs and likely make the code more difficult for apache module
writers to understand.

>
> > 2. Including a buffering filter in the core is wrong for the reasons I
> > stated in my earlier post, and therefore it gives entirely the wrong
> > message to 3rd party developers. If we include something like this in
> > the core then we are compromising the design, and we are encouraging
> > our users to do the wrong thing.
>
> This I will agree with.  I do not believe we really need a buffering
> filter, and at the very least, we don't have enough experience to know if
> we need one or not.

Tony,
Right now the buffer filter is serving a very real purpose. I can reduce 2000+
iovecs into 3.  It works. Like I said earlier, if a better solution comes along,
I'll gladly remove buffer filter. If you are not prepared to offer a better
solution to the problem, then you have no right to veto. Okay, maybe you have a
right to veto, but I have the right to ignore it (at least for now :-).

Bill




Mime
View raw message