You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/04/15 05:36:24 UTC
[patch] s/APR::URI::default_port_for_scheme/APR::URI::port_of_scheme/
This is an updated patch to adjust for the C API change. Should we go with it
or use the deprecated form? FYI, it was default_port_for_scheme in the mp1 API.
Index: Changes
===================================================================
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.171
diff -u -r1.171 Changes
--- Changes 14 Apr 2003 23:36:55 -0000 1.171
+++ Changes 15 Apr 2003 03:33:31 -0000
@@ -10,6 +10,9 @@
=item 1.99_09-dev
+s/APR::URI::default_port_for_scheme/APR::URI::port_of_scheme/ to sync
+with modified C API [Stas]
+
similar to SetEnv, upcase the env keys for PassEnv on platforms with
caseless env (e.g. win32) [steve.sparling@ps.ge.com]
Index: lib/Apache/compat.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.85
diff -u -r1.85 compat.pm
--- lib/Apache/compat.pm 11 Apr 2003 07:34:03 -0000 1.85
+++ lib/Apache/compat.pm 15 Apr 2003 03:33:31 -0000
@@ -545,7 +545,11 @@
*validate_password = \&APR::password_validate;
-sub Apache::URI::parse {
+package Apache::URI;
+
+*default_port_for_scheme = \&port_of_scheme;
+
+sub parse {
my($class, $r, $uri) = @_;
$uri ||= $r->construct_url;
Index: src/modules/perl/modperl_apache_includes.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_apache_includes.h,v
retrieving revision 1.20
diff -u -r1.20 modperl_apache_includes.h
--- src/modules/perl/modperl_apache_includes.h 24 Feb 2003 00:02:44 -0000 1.20
+++ src/modules/perl/modperl_apache_includes.h 15 Apr 2003 03:33:31 -0000
@@ -54,4 +54,8 @@
#define apr_time_from_sec(sec) ((apr_time_t)(sec) * APR_USEC_PER_SEC)
#endif
+#ifndef apr_uri_port_of_scheme
+#define apr_uri_port_of_scheme apr_uri_default_port_for_scheme
+#endif
+
#endif /* MODPERL_APACHE_INCLUDES_H */
Index: t/response/TestAPI/rutil.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/rutil.pm,v
retrieving revision 1.6
diff -u -r1.6 rutil.pm
--- t/response/TestAPI/rutil.pm 3 Mar 2003 02:41:15 -0000 1.6
+++ t/response/TestAPI/rutil.pm 15 Apr 2003 03:33:31 -0000
@@ -43,7 +43,7 @@
ok $r->get_limit_req_body || 1;
while(my($scheme, $port) = each %default_ports) {
- my $apr_port = APR::URI::default_port_for_scheme($scheme);
+ my $apr_port = APR::URI::port_of_scheme($scheme);
#$r->puts("$scheme => expect: $port, got: $apr_port\n");
ok $apr_port == $port;
}
Index: xs/maps/apr_functions.map
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v
retrieving revision 1.49
diff -u -r1.49 apr_functions.map
--- xs/maps/apr_functions.map 15 Apr 2003 02:26:28 -0000 1.49
+++ xs/maps/apr_functions.map 15 Apr 2003 03:33:32 -0000
@@ -566,7 +566,7 @@
uptr, flags=APR_URI_UNP_OMITPASSWORD | unparse
#special case to set both uri->port and uri->port_str
mpxs_APR__URI_port | | uri, portsv=Nullsv
- apr_uri_default_port_for_scheme
+ apr_uri_port_of_scheme
!MODULE=Apache::XML
apr_text_append
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: 2.0 API freeze (or lack thereof)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>> well, I think that this goes to the heart of of the 2.0 project -
>>> what's the official line on API freeze?
>>
>>
>>
>> First of all you have to differ between Apache API and APR API, these
>> are two different beasts. Apache is not responsible for APR API per
>> se. APR's API is planned to be frozen by 1.0 release (which should be
>> one of the next releases).
>
>
> I think you took what I was saying the wrong way :)
>
> actually, I meant the mod_perl 2.0 API, which includes interfaces for
> both Apache and APR, right?
Yup, one can really look at the APR part as a sub-project, which eventually
should have a life on its own (you can use APR outside mod_perl).
>> But people have already started using the existing API, so we can at
>> least try to make their upgrades less painful.
>
>
> yup. but we're still in 1.99, so I think we have some wiggle room.
>
> my point to everything was merely that if APR changes it's API from
> foo() to bar() and mod_perl provides a direct mapping for that feature,
> we should just change it from foo() to bar() as well if that means that
> the underlying software design is better off.
>
> at least until we reach an official 2.0 version, at least.
>
> personally, I'm going to get hit with API changes - I have a 2.0 module
> on CPAN and am in the middle of writing the third perl.com article on
> this stuff (on conditional GETs and filters, which requires both the
> FilterPreHandler and pconf-based cleanups :) - but I think that it's
> understood by the community that things may change until we reach 2.0.
Agreed, but that doesn't mean that we shouldn't try to make the transition
process easier. Not everyone is following cvs commits and this mailing list.
So at least maintaining the API changes list would be useful. May be just
listing them with all other Changes will do ;)
>>> and missing (finfo) parts,
>>
>>
>> That one will probably won't exist at all in mp2.
>
>
> yucko. so we're stuck manually stat'ing $r->filename and won't have
> access to the cached data? that just doesn't seem right. double yucko.
Have you read the patch/comment from Gozer?
Date: Wed, 12 Feb 2003 11:01:48 +1100
Subject: Re: [patch] $r->finfo
References: <10...@exarkhun.eXtropia.com>
Philippe M. Chiasson wrote:
> Currently there is no way to convert from apr_finfo_t to struct finfo.
>
> But, at least, here is a finfo patch that works.
>
> Drawbacks for now is that it will resort to a stat() call each time
> used, and can't be assigned to like you used to be able to do in 1.x
> land (was this feature used at all?)
>> The difference is that Apache::Test was never released to public in
>> any form. It was coming with mp2 to run mp2's tests.
>
>
> well, it's released under httpd-test, and I know of a handful of CPAN
> modules for mod_perl 1.0 that use it (besides my own, even :). so, I
> guess that I think there is more end-user pain involved in changing
> Apache::Test than the mod_perl 2.0 API. but that's just me :)
Really? I didn't know that. I guess I learn about things when something
doesn't work ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: 2.0 API freeze (or lack thereof)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> well, I think that this goes to the heart of of the 2.0 project -
>> what's the official line on API freeze?
>
>
> First of all you have to differ between Apache API and APR API, these
> are two different beasts. Apache is not responsible for APR API per se.
> APR's API is planned to be frozen by 1.0 release (which should be one of
> the next releases).
I think you took what I was saying the wrong way :)
actually, I meant the mod_perl 2.0 API, which includes interfaces for
both Apache and APR, right?
> But people have already started using the existing API, so we can at
> least try to make their upgrades less painful.
yup. but we're still in 1.99, so I think we have some wiggle room.
my point to everything was merely that if APR changes it's API from
foo() to bar() and mod_perl provides a direct mapping for that
feature, we should just change it from foo() to bar() as well if that
means that the underlying software design is better off.
at least until we reach an official 2.0 version, at least.
personally, I'm going to get hit with API changes - I have a 2.0
module on CPAN and am in the middle of writing the third perl.com
article on this stuff (on conditional GETs and filters, which requires
both the FilterPreHandler and pconf-based cleanups :) - but I think
that it's understood by the community that things may change until we
reach 2.0.
>
>> and missing (finfo) parts,
>
> That one will probably won't exist at all in mp2.
yucko. so we're stuck manually stat'ing $r->filename and won't have
access to the cached data? that just doesn't seem right. double yucko.
> The difference is that Apache::Test was never released to public in any
> form. It was coming with mp2 to run mp2's tests.
well, it's released under httpd-test, and I know of a handful of CPAN
modules for mod_perl 1.0 that use it (besides my own, even :). so, I
guess that I think there is more end-user pain involved in changing
Apache::Test than the mod_perl 2.0 API. but that's just me :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: 2.0 API freeze (or lack thereof)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> was Re: [patch]
> s/APR::URI::default_port_for_scheme/APR::URI::port_of_scheme/
>
>
>> OK, then we have a little problem with people who have started using
>> the old API which should be phases out. We have two choices to take:
>>
>> 1) simply change the API, removing the old one and let users adjust
>> their code
>>
>> 2) having a phase-out process where we add Apache/deprecated.pm with
>> all the right aliases and the first time the function is used we log
>> to error_log the function's TTL (time-to-live), for example suggesting
>> that all deprecated functions are to be removed by the golden release.
>>
>> Of course it's much easier to go with (1) ;)
>>
>> There were quite a few changes in the APR's API that need to be
>> propogated to the mod_perl API. (e.g. lots of socket API changes and
>> more).
>
>
> well, I think that this goes to the heart of of the 2.0 project - what's
> the official line on API freeze?
First of all you have to differ between Apache API and APR API, these are two
different beasts. Apache is not responsible for APR API per se. APR's API is
planned to be frozen by 1.0 release (which should be one of the next releases).
I think that Apache API itself is pretty stable at this moment. All the new
developments go into the Apache 2.1 tree.
> personally, I think it should all up for grabs until we the official
> "2.0" release to CPAN, that it should be understood the API can change
> without notice or back compat.
But people have already started using the existing API, so we can at least try
to make their upgrades less painful.
> as I play around with 2.0, there still seem to be lots of unfinished
> (filters)
Which ones are you talking about? Other than the TIE interface the filters API
is pretty complete IMHO.
> and missing (finfo) parts,
That one will probably won't exist at all in mp2.
> so even more changes are
> forthcoming, and I don't think that issues that arise while working
> through these API changes should be hindered by back compat while we're
> still essentially in beta (or less in some areas :)
>
> and, quoting stas from test-dev:
>
> > In any case Apache::Test wasn't released yet, so any API
> > changes are OK, IMHO.
The difference is that Apache::Test was never released to public in any form.
It was coming with mp2 to run mp2's tests.
> and Apache::Test is probably more used at this point than 2.0 :)
>
> so, I guess I'm thinking that we should make the API right, especially
> in cases where mod_perl is serving as true glue between Perl and another
> API (like APR) and not worry too much about the consequences (for the
> moment). however, if this is our stance, then it really needs to be
> public, like in the INSTALL and website.
Well, I suggest that we at least maintain a file that documents the API
changes between release versions.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
2.0 API freeze (or lack thereof)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
was Re: [patch] s/APR::URI::default_port_for_scheme/APR::URI::port_of_scheme/
> OK, then we have a little problem with people who have started using the
> old API which should be phases out. We have two choices to take:
>
> 1) simply change the API, removing the old one and let users adjust
> their code
>
> 2) having a phase-out process where we add Apache/deprecated.pm with all
> the right aliases and the first time the function is used we log to
> error_log the function's TTL (time-to-live), for example suggesting that
> all deprecated functions are to be removed by the golden release.
>
> Of course it's much easier to go with (1) ;)
>
> There were quite a few changes in the APR's API that need to be
> propogated to the mod_perl API. (e.g. lots of socket API changes and more).
well, I think that this goes to the heart of of the 2.0 project - what's the
official line on API freeze?
personally, I think it should all up for grabs until we the official "2.0"
release to CPAN, that it should be understood the API can change without
notice or back compat.
as I play around with 2.0, there still seem to be lots of unfinished
(filters) and missing (finfo) parts, so even more changes are forthcoming,
and I don't think that issues that arise while working through these API
changes should be hindered by back compat while we're still essentially in
beta (or less in some areas :)
and, quoting stas from test-dev:
> In any case Apache::Test wasn't released yet, so any API
> changes are OK, IMHO.
and Apache::Test is probably more used at this point than 2.0 :)
so, I guess I'm thinking that we should make the API right, especially in
cases where mod_perl is serving as true glue between Perl and another API
(like APR) and not worry too much about the consequences (for the moment).
however, if this is our stance, then it really needs to be public, like in
the INSTALL and website.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [patch] s/APR::URI::default_port_for_scheme/APR::URI::port_of_scheme/
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> This is an updated patch to adjust for the C API change. Should we go
>> with it or use the deprecated form? FYI, it was
>> default_port_for_scheme in the mp1 API.
>
>
> I'd rather see the mod_perl API follow the C API as much as possible -
> it helps people know what to look for when they scour the apache source
> for ap_ functions.
OK, then we have a little problem with people who have started using the old
API which should be phases out. We have two choices to take:
1) simply change the API, removing the old one and let users adjust their code
2) having a phase-out process where we add Apache/deprecated.pm with all the
right aliases and the first time the function is used we log to error_log the
function's TTL (time-to-live), for example suggesting that all deprecated
functions are to be removed by the golden release.
Of course it's much easier to go with (1) ;)
There were quite a few changes in the APR's API that need to be propogated to
the mod_perl API. (e.g. lots of socket API changes and more).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [patch] s/APR::URI::default_port_for_scheme/APR::URI::port_of_scheme/
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> This is an updated patch to adjust for the C API change. Should we go
> with it or use the deprecated form? FYI, it was default_port_for_scheme
> in the mp1 API.
I'd rather see the mod_perl API follow the C API as much as possible - it
helps people know what to look for when they scour the apache source for ap_
functions.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org