httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: filtering patches
Date Tue, 11 Jul 2000 03:15:41 GMT

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


Mime
View raw message