httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: [PATCH] ap_add_filter
Date Fri, 18 Aug 2000 21:55:10 GMT
A couple of things I missed; I was still waking up.

On Fri, Aug 18, 2000 at 11:59:52AM -0700, Manoj Kasichainula wrote:
> On Fri, Aug 18, 2000 at 07:14:02AM -0700, wrote:
> > 
> > > OK, a thought that fell out while writing up my design proposal for
> > > 3.0.
> > > 
> > > I think think there will be scenarios where filters need to add
> > > new filters both before and after themselves. To me, it seems kind of
> > > scary to let every single filter operate directly on the "main"
> > > filter chain as well.
> > 
> > Could you please give an example of such a filter?

A contrived one given a couple of minutes of thought but:

you have a running PHP script. It has been told to #include (or
whatever the PHP equivalent is) another PHP script. But that script
happens to be gzipped.

But, I didn't actually mean to say what I said, even though it's true. :)
I meant to say that there are cases where a filter wants to insert
itself both at the beginning and end of the list of filters that it
adds to the chain. The design I propose handles all of these cases by
giving a filter complete and arbitrary control over its personal
filter chain.

> constructor {
>     me->filter_chain_head = me->filter_func_impl;
>     me->filter_chain_tail = me->filter_func_impl;
> }
> me->filter_func() { // this is the filter->write() function, right?
>     me->filter_chain_head();
> }

Note that this is the only new code that a filter needs to have. The
other functions I listed were just common linked list functions that
we will include anyway.

> > I have no problem 
> > letting modules munge the main filter stack themselves.
> Well, if this can be avoided with very simple code, I'd just as soon
> avoid it.

The reasons I want to avoid this are the principles of information
hiding and touch-as-little-as-possible. With a very small amount of
added code and some slightly changed procedures, you end up completely
isolating a filter's operations from the main filter chain completely.
The top-level filter chain can be "owned" completely by the main
server, and never changed throughout a request. That's just nice. :)

View raw message