httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] ap_add_filter
Date Thu, 17 Aug 2000 23:28:31 GMT
On Thu, Aug 17, 2000 at 09:22:03AM -0700, wrote:
> This is a real patch to ap_add_filter.  The basic idea, is to add filters
> in a stack instead of the queue that we are currently using.  The
> difference, is that filters can specify a filter to be added after.  That
> is incredibly unclear, so let me explain.  :-)
> The API is changed to:
> ap_add_filter(char *name, void *ctx, request_rec *r, ap_filter_t *curr);

This is goodness. Can we add this and defer the FIFO/LIFO thing? I still
think that the LIFO is not going to solve the basic problem: filter
insertion time can be non-deterministic, thus we can never insert them in
the proper time-based order, therefore we need some internal classification
of the filters to ensure proper ordering (among classes).

I've also seen that the connection/transport filters probably operate more
like a prepend-list, while the content filters are more like today's

[ I just realized that FIFO/LIFO don't make sense. First-In-First-Out? in
  and out of what? Filters are appended or prepended to the chain. We never
  pop/remove them, so the FIFO/LIFO term doesn't apply ]

I think that the switch from append-style to prepend-style is based on the
experience of just the chunking filter. What happens with the next filter?
And after that? Let's keep the mechanism as we originally planned until we
see more examples and have more details on the model.

There is also the insert_filter hook ordering vs filter ordering. Reversing
these irks me a bit. This flipped model, in conjunction with the
non-deterministic nature of inserting filters makes me say that we shouldn't
flip the sequence (now).

Summary: can we add the "next" stuff and defer the prepend/append thing
until we have more experience with actual filters?

IOW: -1 on the prepend/append. +1 on the "next" param to add_filter.


Greg Stein,

View raw message