httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <ma...@io.com>
Subject Re: [PATCH] ap_add_filter
Date Sat, 19 Aug 2000 08:47:42 GMT
On Fri, Aug 18, 2000 at 03:17:14PM -0700, rbb@covalent.net wrote:
> > 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 that is perfectly possible without all of this.  For example:
> if PHP_Filter had the following in it:
> 
> PHP_filter{
>       ap_add_filter(PHP_FILTER)
>       ap_add_filter(gzip_filter)
> }
> 
> And we had the filter stack
> 
> PHP_FILTER --> INCLUDE_FILTER --> CORE_FILTER
> 
> After PHP_filter was called, we would get:
> 
> PHP_FILTER -> gzip_filter -> PHP_FILTER -> INCLUDE_FILTER -> CORE_FILTER

You can't use two seperate PHP filters. There can be variable
settings or function calls or whatever from the included file that
are needed by the original script.

> > > 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();

OK, this last line should've been
          me->filter_chain_head->filter_func();
> > > }

> This function doesn't make sense.  The filter_func field is the filter
> function, i.e. chunk_filter or core_filter/

Exactly. It is the function called by ap_pass_brigade, right? That
doesn't change in this proposal.

> I would actually think the code would look more like:
> 
> ap_filter_t has an ap_filter_t *sublist added to it.

Sort of. I named it filter_chain_head instead, and it's private to the
filter, so a filter that manages its own filter chain looks the same
to the outside world as one that doesn't need to.

> ap_pass_brigade is what calls the next filter, but it is passed the next
> filter, not the current one, so every module would need:
> 
> if (current_filter->sublist)
>     ap_pass_brigade(current_filter->sublist, brigade)
> else
>    ap_pass_brigade(current_filter->next, brigade)

The purpose of the constructor/initialization above was to make this
unnecessary.

> Then pass_brigade would need to be modified to not return an error when
> the current filter is NULL

How does current_filter become null under the scheme I'm proposing?

> > 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. :)
> 
> Unfortunately, the design is incredibly ugly to avoid all of those things
> in C.  It is possible, but it isn't clean at all.

I disagree. I think this is cleaner than the other proposals I've seen
with LIFO vs. FIFO, etc. 


Mime
View raw message