You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 2001/04/29 21:39:15 UTC
Connection and request filters?
Why do we pass request and connection to ap_add_*_filter? If we pass a
request, the connection is redundant, and currently passing NULL for the
request means use the connection - however we always pass the
connection, and, indeed, I think code relies on that. This strikes me as
unclean and mildly confusing. I'd rather have ap_add_request_*_filter
and ap_add_connection_*_filter (even if they are just wrappers for what
we've got) - what do people think?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
ApacheCon 2001! http://ApacheCon.com/
Re: Connection and request filters?
Posted by rb...@covalent.net.
On Sun, 29 Apr 2001, Ben Laurie wrote:
> rbb@covalent.net 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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Connection and request filters?
Posted by Ben Laurie <be...@algroup.co.uk>.
rbb@covalent.net 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?
> 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?
Cheers,
Ben.
> Just my 0.02 though, feel free to change it
> if everybody else wants to.
>
> Ryan
>
> On Sun, 29 Apr 2001, Ben Laurie wrote:
>
> > Why do we pass request and connection to ap_add_*_filter? If we pass a
> > request, the connection is redundant, and currently passing NULL for the
> > request means use the connection - however we always pass the
> > connection, and, indeed, I think code relies on that. This strikes me as
> > unclean and mildly confusing. I'd rather have ap_add_request_*_filter
> > and ap_add_connection_*_filter (even if they are just wrappers for what
> > we've got) - what do people think?
> >
> > Cheers,
> >
> > Ben.
> >
> > --
> > http://www.apache-ssl.org/ben.html
> >
> > "There is no limit to what a man can do or how far he can go if he
> > doesn't mind who gets the credit." - Robert Woodruff
> >
> > ApacheCon 2001! http://ApacheCon.com/
> >
> >
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: Connection and request filters?
Posted by rb...@covalent.net.
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. It also makes it harder to find everywhere that we add output
filters in the entire server. Just my 0.02 though, feel free to change it
if everybody else wants to.
Ryan
On Sun, 29 Apr 2001, Ben Laurie wrote:
> Why do we pass request and connection to ap_add_*_filter? If we pass a
> request, the connection is redundant, and currently passing NULL for the
> request means use the connection - however we always pass the
> connection, and, indeed, I think code relies on that. This strikes me as
> unclean and mildly confusing. I'd rather have ap_add_request_*_filter
> and ap_add_connection_*_filter (even if they are just wrappers for what
> we've got) - what do people think?
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
> ApacheCon 2001! http://ApacheCon.com/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------