On Sun, 29 Apr 2001, Ben Laurie wrote:
> [EMAIL PROTECTED] 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
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
