Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 26 Jun 2000 13:36:44 -0700
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: [PATCH] link-based filtering
Message-ID: <20000626133644.V29590@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <20000626124906.P29590@lyra.org>
 <Pine.LNX.4.21.0006261313080.23952-100000@koj.rkbloom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.21.0006261313080.23952-100000@koj.rkbloom.net>;
 from rbb@covalent.net on Mon, Jun 26, 2000 at 01:20:21PM -0700

On Mon, Jun 26, 2000 at 01:20:21PM -0700, rbb@covalent.net wrote:
> 
> > > 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/

What? There is only one BUFF in the output chain: the one at the bottom,
sitting in front of the socket's IOL. Therefore, you only have a single
memcpy(), just like today.

> > 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.

Hmm. I'll have to see your patch, then. I believe the ap_l* calls are very
helpful in getting the content passed along. OtherBill had a big concern
that the filters weren't going to be passing the content "down" correctly,
that if each filter is responsible for the logic to do that, then they could
get messed up.

> I also remove the ability to write
> char *'s to filters, which I believe reduces complexity by having only one
> interface to the layering.

As I stated in the other mail, the second, simplistic API reduces a bunch of
complexity. People can write a simple char* processor and be done with it.
Having two types of callbacks is not complicated: as I mentioned before, Jim
recognized the different immediately, and understood "why" it was that way.

> This also makes it incredibly easy to move to
> Roy's bucket brigades over time instead of all at once.

The ap_bucket_t is directly applicable to moving towards a bucket brigade.
The presence of simple_cb does not hinder any progression towards that end.

> > > 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.

I get the feeling that you didn't really look at it, then. This is certainly
not the case. There are no BUFF objects in the filtering code.

At the bottom of the chain, just like today, the BUFF exists.

> > > 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?

If the module is going to insert the thing itself, it needs an
insert_filter. If it has two filter with very different timing requirements,
then yah: it'll get a bit tweaky.

However, I'll repeat yet again: I do not believe that insert_filter will be
used all that much. I think they will be inserted by an (external) SetFilter
directive, or similar. The SetFilter will ensure the proper ordering.

If insert_filter *is* used, then there is an even lower probability that
some joker out there is going to install two filters, and where those
filters must be interleaved with other filters in the system.

> 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.

Because of the need to usually use SetFilter, I determined that the
classifications are pointless. You have two classes: content, and
connection. That is all.

Consider that you could have multiple content encodings and they need to be
manually ordered within their class (via SetFilter). Socket encoding: the
same. Digest/messaging? Doesn't matter when the hell they run since they
don't tweak the content. Content recoding? That will probably happen just
once, so it is technically possible to create a special class just for that.
I found that would be assymetric and punted.

The only different between "content" and "connection" filters is that the
latter cannot be used on a subrequest. Otherwise, there is no true
distinction among the classes of filters, since an implicit "class ordering"
will be ignored in favor of an explicit ordering defined by a SetFilter
directive.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/