httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] link-based filtering
Date Mon, 26 Jun 2000 20:20:21 GMT

> > It isn't mod_cgi that is going to use the iovec, it's mod_include.  That
> > is, unless mod_include is going to memcopy all of those into a BUFF.
> Copying into a BUFF is what happens today, and I see no reason that it
> wouldn't or shouldn't in the future.

Because if we continue to copy into BUFF, then most modules will be doing
their own memcpy's into BUFFs.  This means that if you have three or four
modules, you copy the data three or four times.  I don't believe this is
necessary or good/

> When you post your patch, please hilite the *differences* from my patch.
> That is where the discussion will take place.

The biggest difference will be that I am removing the indirect recursion,
by getting rid of the ap_l* calls.  I also remove the ability to write
char *'s to filters, which I believe reduces complexity by having only one
interface to the layering.  This also makes it incredibly easy to move to
Roy's bucket brigades over time instead of all at once.

> > and most of buff.c can be
> > removed and replaced by modules.  Plus, mod_ssl becomes simplistic.  
> I suspect either patch set will allow this.

You're patch relies on Buff to do the layering.

> > The addition was obvious.  I just fear that once you add it, you'll see
> > that it looks a lot like the hooks stuff.  If it looks at all like the
> > hooks stuff, then my next patch becomes absolutely beautiful.  :-)
> Nope. It is very simple, and doesn't look at all like the hooks. No need for
> that. Since a module can register their "install_filters" hook with a
> specific ordering, then any filter addition will follow that ordering. I
> also suspect that all filtering will be done using SetFilter or the like,
> which defines a specific ordering to the addition of filters.

So, does that mean that a module will have to implement an insert_filter
function for each filter it implements?  I really dislike that.  I do not
see how this can possibly work if a module has multiple filters.  Plus, I
see no way to order based on the four different types of filters we
discussed (I am ignoring generators, because those are handlers).  You
have two types of filters, content and connection.  We have listed five
different types, which needed to be run in a specific order.

This patch does not handle that.

> Okay. But I will say again: you can save that hour or so, as I believe my
> patch address all of your technical concerns.

See above.


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

View raw message