httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: [PATCH] bucket problems.
Date Wed, 17 Jan 2001 19:02:23 GMT wrote:
> > > was required to make mod_autoindex work.  That is the other half of this
> > > patch, I have modified mod_autoindex to use those functions instead of
> > > ap_r* to actually write the data for the request.
> >
> > One obvious question: is there a _really_ good reason to change the name
> > of ap_rputs?  This dumps unnecessary work onto the module authors IMO,
> > at a time we are trying to stabilize the code base.  If this code is
> > solid, why not just hijack the ap_rputs entry point?
> A couple of reasons.
> 1)  ap_r* functions are httpd specific, 

... and that's what Apache modules are for the most part....

>                           these need to be brigade
> functions.

at the plumbing level, yes.  at the module API level, booooo!! 

> 2)  ap_r* functions work on a request_rec, these work on a bucket_brigade,
> so calling them ap_r* doesn't make any sense, because there is no r.
> 3)  Even if we kept the function name the same, the API is different, and
> if somebody is going to go in and modify the ap_rputs call to pass a
> bucket_brigade instead of a request_rec, they can change the name too.  I
> also fully expect that the ap_r* functions will go away completely, but
> this allows us to have a working server for the day it will take to make
> that happen.

How about turning ap_r* into httpd-specific wrappers that know how to
call your new functions, while presenting the current API appearance to
Apache modules?  The wrappers would have to know how to get a brigade
from the r, of course.  Then everybody works on day 1 with no
effort/code churn in module land.  If we later find out that the cost of
the wrappers actually matter in some cases, we can change individual
modules in a controlled manner.

I see a lot of changed lines in mod_autoindex, and they're not doing
anything worth bragging about at ApacheCon.

> > One thing that I will be looking for is what will cost of the *average*
> > ap_rputs/ap_brigade_puts call be with the new close will it
> > come to 1.3?  It needs to be not much more than one or two function
> > calls, a few tests, and a copy into the buffer.
> The average ap_brigade_puts call is a simple memcpy, and that is it.  

Coool!  I was hoping that was the case.  


View raw message