httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Connection and request filters?
Date Sun, 29 Apr 2001 23:23:57 GMT
On Sun, 29 Apr 2001, Ben Laurie wrote:
> wrote:
> >
> > I personally like the setup we have now.  It is a relatively simple API
> > IMO.  We currently have two entries to the same general function
> > add_any_filter, one for input and one for output filters.  I believe that
> > splitting each of these in two for conn and request based filters is
> > overkill.
> OK, where I'm coming from is that function prototypes should reflect
> functionality - if it is a request filter, the connection argument isn't
> really used, is it? (Though it currently has to because it is used
> unnecessarily).
> Your argument essentially seems to be that we shouldn't do it because
> there's some benefit in having fewer APIs. Tell you what, why don't we
> do the entire API with a single function?
> union all_types *ap_do_everything(enum function_type type,...);
> :-) There, isn't that tidy?

No, that's impossible to use.  :-)  My argument is to not expand the API
unnecessarily.  Maybe this is a needed change, I am okay with doing it,
although it wouldn't be my first choice.  I gave one reason for not doing
it is all.

BTW, the conn_rec is not currently used unless the request_rec is not
passed in.

> >  It also makes it harder to find everywhere that we add output
> > filters in the entire server.
> Weird argument - what's hard about:
> grep 'ap_add_*_output_filter'
> or similar?

I didn't say it was hard, I said it was harder than

grep "ap_add_output_filter"

As I said, feel free to do it if everybody else wants to, it just wouldn't
be my preference.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message