Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 10 Jul 2000 20:15:41 -0700 (PDT)
From: rbb@covalent.net
To: new-httpd@apache.org
Subject: Re: filtering patches 
In-Reply-To: <200007101657.aa21782@gremlin-relay.ics.uci.edu>
Message-ID: <Pine.LNX.4.21.0007102011110.16616-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> >I don't think the stack is less efficient than hooks.  It just makes less
> >sense to me.  If we use a stack (as I think of it), then each filter has
> >to re-add itself to the stack after it is done executing.  Since I think
> >most filters will end up being called multiple times, it makes more sense
> >to me to remove the filters that we are done with, then to add back the
> >ones we aren't done with.  Does that make sense?  I would really
> >appreciate it if you could look at my latest patch, and make sure we are
> >thinking of the same thing when we talk about a filter stack.
> 
> It looks like we aren't. ;-)

Oh, GOOD!  I thought this was an insanely stupid way to do things as I was
writing the code.  I will remove that patch completely from my hard drive,
because that was a horrible thing.  :-)  I am leaving the original
bucket_brigades patch alone.

> I meant that the filters, when written to as part of the output stream,
> are treated as a stack (write to the top-most filter without any knowledge
> of what may lie underneath it).  So the process of arranging filters
> for a particular response is like dropping them onto a stack.  When a
> filter is done or the stream is closed, each instantiated filter cleans
> up according to its local state and then destroys itself (as it is popped
> off the stack).

Yes, okay, that makes perfect sense.  That is what the hooks should do
given enough time to finish them.  I have a couple of things I want to do
with them, but it has to wait until I isolate this damn seg fault.

> This is completely separate from the registration of filters by
> name and purpose, which could be done by hooks.  The difference is that
> filters are registered at config time but only instantiated (given local
> storage) and arranged on a per stream basis.

Yes.  This is what both of the current patchs (my original one and
Greg's) do.

> Would it be possible to agree on a directory within APR that would house
> prototypes for ap_buckets.c and ap_brigades.c and ap_filters.c, and then
> commit both Greg's and Ryan's files to that directory?  There is so much
> more that I could do if I weren't spending all of my free time trying to
> catch up to the current "state" of the sandbox.  It doesn't need to be
> tied into the server yet.

Have at it.  The directory is lib/apr/buckets.  This code isn't tied into
the server at all yet.

Ryan

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