httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] link-based filtering
Date Mon, 26 Jun 2000 20:14:40 GMT
On Mon, Jun 26, 2000 at 12:49:44PM -0700, wrote:
> > The "other types of pointers" are handled using buckets. If you're writing a
> > simple, dumb-ass filter, then you get a char*.
> > 
> > Basically, the patch that I've posted gives people two options to filter
> > development:
> > 
> > 1) give me something simple
> > 2) that isn't fast enough, give me the metal and I'll just deal
> > 
> > In other words, it has a very low starter bar. Experienced developers can go
> > right for the muscle.
> It also confuses people immensly.  Imagine the first time you go to write
> a filter, and there are two different API's for filters.  I really dislike
> that.  And, filters that want to DO anything are going to use
> buckets.  Get rid of the char *'s completely.

Euh... I disagree. The difference of the two styles is very easily
clarified. I did that in a post just a bit ago, and Jim went "cool". I think
he understood the difference right away, and could approach the problem from
whichever angle he chose.

And there aren't two APIs: just two types of callbacks. The author selects
one or the other. The rest of the filter API and structure is the same.

Regarding "doing" something. I think both approaches are quite valid. In my
mod_gargle example, I demonstrated how each approach could be selected for
the problem at hand.

Option (1) was selected for the character processing. It needed to touch the
characters directly and had little room for optimization. (1) was the best
approach for that filter.

Option (2) was selected for the header/footer thing. In that case, it was
blindly jamming stuff onto the front/end of the output stream. It didn't
care what was inside, or how the data was structured (e.g. bucket type).

> I have the patch 99% done.  I'll post soon.
> Also, after all the talk of ordering filters, I don't see how your patch
> allows module writers to order their filters.  It lets them add filters,
> but not order them appropriately.

Module writers have two options of adding filters in a particular ordering:

1) use the ordering information of the "install_filters" hook
2) depend on SetFilter (or similar) to insert the filter.
   NOTE: in my patch, all the filters are named, thus allowing external
         systems (such as SetFilter) to insert the filters.

IMO, option (2) will almost always be used

I'm not sure what additional ordering is necessary.


Greg Stein,

View raw message