httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] bucket problems.
Date Wed, 17 Jan 2001 19:21:51 GMT

> 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

Where are you going to put the brigade?  You can't put a brigade into the
request_rec.  It doesn't belong there.  You have no idea what later
modules are going to do with that brigade.  Plus, now each filter has two
brigades, one from the request_rec, and one from the argument list.  Which
one should be used?  How are you going to document that the brigade in the
request_rec is only valid in the handler phase?  Why are we adding more to
the request_rec?  Apache 2.0 supports the ability to add more protocols,
and many of those are going to be hampered by needing a request_rec, we
should be ripping stuff out of that structure, not adding more.

> effort/code churn in module land.  If we later find out that the cost of

It is absolutely impossible for modules to just work out of the box.  Get
that whole idea out of your head please.  The module writer is going to
need to control passing the brigade down to the next filter.  If the ap_r*
functions remain, modules will continue to compile, but they won't
work.  Try removing the call to ap_pass_brigade from mod_autoindex, and
run it.  You won't get any data.

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

So what!  This has nothing to do with making changes that we can brag
about.  This has to do with what is the correct approach for the module
writer.  In Apache 1.3, module authors were writing data for the
request.  In Apache 2.0, module writers are writing data for the next
filter.  The ideas are different, and how they are treated are
different.  The big problem we had with keeping the ap_r* functions, is
that they don't have the correct information to work successfully.  This
solves that by giving the functions the correct fields.

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



Mime
View raw message