httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: BIG filtering patch.
Date Sat, 08 Jul 2000 02:24:55 GMT
On Fri, Jul 07, 2000 at 08:29:54AM -0700, wrote:
> > We don't
> > want filters to be self-sorting in any case, since that would
> > interfere with layered encodings and subrequests.  
> I guess I don't see this, but I am willing to be educated.  In my mind, it

For the record, I'm with Ryan on this one. I *do* believe that some amount
of "self-sorting" is required. I don't think that Apache is deterministic
enough to ensure that the control flow will push filters onto a stack in the
correct order.

> 2)  We add a content filter while we are filtering the data.  In my head,
> the function that is inserting the filter has to know enough to put the
> new filter into the list after the current filter.  The sorting algorithm
> shouldn't touch it, because when we inserted it into the list, we gave it
> the right number.
> Having said all of that.  I kept that section of my latest patch as clean
> as possible for a reason.  If people really want to remove the hooks
> stuff, it should be relatively easy to do.  We need a way for filters to
> easily insert their filters, and those filters need to be
> order-able.  Greg's patch relied on the insert-filter hook to do the
> ordering.  My patch asks the filters to order themselves.  I haven't given
> any thought to how a stack would work, but my gut feeling is that it
> wouldn't be great, simply because we take the chance of asking mod_include
> to run after we have gzip'ed the data.

Clarification here: my patch allows filters to specify their ordering in two
ways: the insert-filter hook, and by filter "type". I have defined only two
types at the moment because I wasn't sure we needed more granularity.
However, it is simply an enum, so we can have types that match up to each of
those Ryan listed later in this email.
[ this "type" is effectively a self-sorting thing for filters ]

I'm with Ryan on not understanding how a "stack" would work in the Apache
execution environment. I much prefer the types of ordering mechanisms that
are in mine and Ryan's patches. (I disagree with his using ap_hooks to do
it, but will take it over a stack any day :-)

I'll also point out that my ap_add_filter() adds filters "at the end"
(meaning "after") of the particular group. In other words, a content filter
can add a filter and be guaranteed it will be inserted after "self".

> > I think if we can agree on an answer to that one question then it will
> > be relatively easy to merge all of our stuff into a single sandbox and
> > jump start a coding frenzy.
> I assume you are talking about the filter stack from Greg's patch, and the
> bucket's from my latest patch.  I can do that merge next week if nobody
> else beats me to it.

If we agree on the linked list that I use in my patches, filter registration
(ap_register_filter), and inserting filters into the linked list
(ap_add_filter), then I would recommend that we simply check that into
Apache today. Certainly, the definition of the callback and bucket
structure(s) will change in one direction or another, but we can get some of
the framework into place (thus reducing the patch set size).

Ryan: if you're okay with the ap_filter_type, ap_filter_t (with a void* for
the bucket_cb field), ap_register_filter, and ap_add_filter concepts and
structures, then I'll extract a sub-patch for just those items and post that
for review.

It would be great to have that in there, much like we have insert_filter
in there already.


Greg Stein,

View raw message