httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: [VOTE] ap_r* model.
Date Fri, 02 Mar 2001 16:15:31 GMT
On Fri, 2 Mar 2001, Greg Stein wrote:
> On Thu, Mar 01, 2001 at 02:17:34PM -0800, wrote:
> > On Thu, 1 Mar 2001, Greg Stein wrote:
> >...
> > > In ADDITION: There is a coupling across subsystems introduced by the r->bb
> > > mechanism. As a result, they will have ordering issues unless they *also*
> > > pay attention to what other pieces are doing.
> >
> > This doesn't exist at all if the sub-systems use ap_r.
> Not all subsystems *are* going to use ap_r*. The whole point of "subsystem"
> means it is an independent unit. Coupling means that the subsystem is no
> longer independent -- it is "coupled" to what its callers/users do.

I should probably have stated that they can either use ap_r or r->bb.
Same thing, and everything will still work.  If the subsystem is going to
use ap_r, then it can interchangibly use r->bb.  If the subsystem wants to
work in a filter as well as a handler, then it had better accept a brigade
as an argument.  The only other way this will work, is for the
handler/filter to send the brigade, but again that means that we have lost
buffering.  Not for the handler case, but what about the filter case?  I
want the handler and the filters to be the same code for a very simple
reason.  If there is a deficiency in the filter or brigade mechanism, it
is found in both handlers and filters.  If the filters and handlers use
the same code, then one fix fixes both, if not, they don't.  You are
proposing that the subsystem problem is solved for handlers by the
OLD_WRITE filter.  Fine.  How are you solving it for filters?  The ap_r*
being macros around ap_f* means that ALL subsystems, those for filters and
handlers are always written the same way, and the issues surrounding them
are the same.  Using OLD_WRITE means that people need to learn one set of
rules for filters and a different one for handlers.  That is the wrong
model, and it violates the principle of least astonishment in a MAJOR way.

I am saying that filters and handlers are the same thing.  If a problem
exists in one, it should exist in the other.  If we are going to fix it
for one, then that same fix should still work for the other.  OLD_WRITE
decouples filters from handlers, and allows us to fix one while the other
is still broken.

BTW, the other advantage that I always forget, is that the macros make
handlers look like filters.  That means it is easier to convert a handler
into a filter and visa-versa.  Don't tell me it won't ever happen, it will
and already has.

> > > > 	If a filter is added in between the handler and the OLD_WRITE
> > > > filter, then the performance improvement disappears.
> > >
> > > While true, it is not a realistic scenario. As I've stated before, the
> > > OLD_WRITE filter should use a filter type such as:
> > >
> > >   #define AP_FTYPE_INTERNAL 0 /* reserved for Apache internal filters */
> > >
> > > Thus, nobody is/should be using that filter type, and no filter will precede
> > > the OLD_WRITE filter.
> >
> > I am thoroughly against this proliferation of filter types, and have been
> > since the beginning.  What happens when Apache needs something to go
> > between the OLD_WRITE filter, and another filter?  We create another
> > filter type?
> That is a red herring.
> The need for Apache to have filtering types is unrelated to the problem at
> hand. You and I discussed this need at ApacheCon. If you want to discuss the
> merits of filter types, then start a new thread, but it should not be mixed
> in with this discussion.

How can this be a red herring?  The OLD_WRITE filter requires another
filter type.  I am against that.  Those two facts together make that a
relavant statement.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message