httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] bucket problems.
Date Wed, 17 Jan 2001 19:27:02 GMT


> rbb@covalent.net 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!!
> hissss!!

The buffer is associated with a brigade. It makes sense to associate the
methods that operate on that buffer with the brigade as well.  Yes,
ap_brigade_blah is a bit long winded (for C code anyways :-) but big deal.  A
handler like mod_autoindex written to this new API will contain two
conceptually new things: a call to ap_brigade_create() and a call to
ap_pass_brigade()).  The other calls (in this handler) that operate on the
brigade are symantically identical to BUFF calls. A handler author doesn't
need to understand all the bucket manipulation API which is the goodness I was
looking for.  I am not quite to the point of wanting to totally eliminate the
ap_r* calls but I'm close.

Bill


Mime
View raw message