httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: Apache 2.0 beta STATUS
Date Mon, 22 Jan 2001 06:11:21 GMT

> Please, Greg and Ryan, document -simply- where your patch stands up and
> the other falls down, so I can grok this quickly without wadeing chin
> deep in the filtering mechanics!

Really simple:

Where my patch stands up:
	
using the apr_brigade_* functions, we collapse small writes into one
bucket

Using apr_brigade_flush() function, it is possible to mix the API's

If we add the apr_brigade_flush call to the brigade macros, we can hide
this from the module author, although I am opposed to that.

It works both inside and outside of Apache, which also means it works for
module authors that want to append data to the end of the brigade.

It looks like an API that programmers are used to.  There is a buffered
and a non-buffered API.  The direct bucket calls are unbuffered, the
brigade calls are buffered.  If you want to switch from buffered to
unbuffered, you have to call apr_brigade_flush.

apr_brigade_flush is incredibly inexpensive.  If it is called and isn't
needed, it is a single if and a return.

A minor point, but it has consistently performed slightly better that the
filter approach.

Where it fails:

In it's current form, it requires the module author to actually call
apr_brigade_flush.  This was a design choice on my part.  I have detailed
how this can be hidden from the module author, but I disagree that we
should.

That's all I can see.  I can back every statement up with code, although
it might take a few hours, because I have been tweaking things
tonight.  :-)

I am going to bed now.  Please, I just want to commit one tomorrow.  I
honestly believe my patch is better for both Apache and apr-util, but I am
not willing to continue arguing.  If we don't reach a real conclusion by
Tuesday morning, I will remove my patch from consideration.  This arguing
doesn't do us any good at all, and it just slows down our progress.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message