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 2004/07/02 01:21:30 UTC
[apr] dropping Apache2/ subdir for APR::*
As we work to really have APR:: independant from mod_perl, I think it also
makes sense to *not* install APR:: into Apache2/ subdir, so that one doesn't
need to load Apache2.pm in order to use APR:: standalone. There is no problem
installing APR libs into the top level, since mp1 didn't have APR.
Though let's think about the future now. What happens when APR 2 is released
(currently we have APR 1, don't confuse with Apache 2.x). How do we ensure
that several APR generations can co-exist under the same perl install?
In fact I think it's quite possible that at some point we will completely
decouple perl-apr from modperl on the repository level (same as apr and
apr-util are not part of the httpd-2.0 repository). So one will be able to
download a source for perl-apr, and not build modperl at all if all they want
is perl apr. Of course for this to happen we need more hands to do the work,
and probably we shouldn't even start to do it now, instead spending all the
resources to get mp2 out first.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@stason.org> [21-11-2004 20:37]:
>
>>Radoslaw Zielinski wrote:
>
> [...]
>
>>> 'Apache/Connection.pm' => [
>>> 'Apache::Connection',
>>> '...',
>>> {
>>> local_addr => sub {
>>> require Apache2::Connection;
>>> require Socket;
>>> require APR::SockAddr;
>>> my $c = shift; # is an Apache::Connection object
>>> my $sockaddr = Apache2::Connection::local_addr($c);
>>> Socket::pack_sockaddr_in($sockaddr->port,
>>> Socket::inet_aton($sockaddr->ip_get));
>>> },
>>> ...,
>>> }
>>> ],
>>
>>and how do you use that?
>
>
>>If I have the code,
>
>
>> $c->local_addr;
>
>
>>which of the implementations will be invoked? At which point $c gets
>>blessed into Apache::Connection and not Apache2::Connection? do you
>
>
> Frankly, I was counting on you with this one... :-) My knowledge on
> perl / mod_perl internals is close to nothing.
That's the problem. I still can't quite understand how exactly you are
going to solve the problem I'm talking about. The devil is in the detail.
>>suggest that if the compat layer that you suggest is loaded mp2 should
>>bless everything ($r, $c, $s, etc.) into Apache::* namespace and not
>>Apache2::* namespace?
>
>
> Oh, come on, that would be unacceptable. The last thing needed here is
> more mess.
That's what I understand (assumed) that you have suggested. If not then
please explain again, since I don't understand how else mp2 will know
which of the two APIs it needs to invoke.
>>How is this going to work if a real mp2 app/module needs to be run under
>>the same perl? Any run-time decision based mechanism will probably
>>introduce a way too much complexity and run-time overhead for mp2, just to
>>support mp1? Or do I miss something?
>
>
> For $r: wouldn't one "bool needs_compat_layer" variable (struct field?)
> per configured handler suffice? That would be one byte and one
> comparison (per request, I guess).
that will mean that it's not possible to mix mp1 and mp2 code. e.g. if you
have some module that works under mp2 only?
> For other objects... I'll think about it.
>
>
>>>Who cares about the C API, since all we need to do is to provide a
>>>compatible perl one? Current Apache::compat already does it, the
>>>namespace change would just remove the need for calling override_mp2_api.
>>
>>Don't forget the overhead of compat implementation too. in the particular
>>case of $c->local_addr, it's more efficient for the app to call
>>$sockaddr->port, $sockaddr->ip_get if it's running under mp2, then doing
>>it in the compat way, where it'll first encode that info into SOCKADDR_IN
>>object, just to decode it back a second later? If I were to code an app
>>that should be run under both, I'd rather explicitly code it differently
>>for each version, which doesn't seem to be possible with your suggested
>>case, since mp2 will now return a wrong thing when called even an explicit
>>function call like Apache2::Connection($c), since $c will be blessed into
>>Apache::Connection. So how do you deal with the situation where you need
>>to be able to call real mp2 methods in the environment where things are
>>emulated?
>
>
> Good point. Quick ugly solution:
>
> local_addr => sub {
> require Apache2::Connection;
> require Socket;
> require APR::SockAddr;
> my $c = bless shift, 'Apache2::Connection';
> my $rval = Socket::pack_sockaddr_in($c->local_addr->port,
> Socket::inet_aton($c->local_addr->ip_get));
> bless $c, 'Apache::Connection';
> return $rval;
> },
>
> No idea for something smarter, however. At least right now.
You mean you rebless it and call the same method again, thus
Apache2::Connection::local_addr is never touched? So it is all governed by
what class the object is blessed into? Man, that's a big big mess. Granted
it might work if one figures out how to juggle the $c (and other) objects.
Still if you ever get a situation that both APIs happen to run under the
same <Location> you are in a big trouble.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [21-11-2004 20:37]:
> Radoslaw Zielinski wrote:
[...]
>> 'Apache/Connection.pm' => [
>> 'Apache::Connection',
>> '...',
>> {
>> local_addr => sub {
>> require Apache2::Connection;
>> require Socket;
>> require APR::SockAddr;
>> my $c = shift; # is an Apache::Connection object
>> my $sockaddr = Apache2::Connection::local_addr($c);
>> Socket::pack_sockaddr_in($sockaddr->port,
>> Socket::inet_aton($sockaddr->ip_get));
>> },
>> ...,
>> }
>> ],
> and how do you use that?
> If I have the code,
> $c->local_addr;
> which of the implementations will be invoked? At which point $c gets
> blessed into Apache::Connection and not Apache2::Connection? do you
Frankly, I was counting on you with this one... :-) My knowledge on
perl / mod_perl internals is close to nothing.
> suggest that if the compat layer that you suggest is loaded mp2 should
> bless everything ($r, $c, $s, etc.) into Apache::* namespace and not
> Apache2::* namespace?
Oh, come on, that would be unacceptable. The last thing needed here is
more mess.
> How is this going to work if a real mp2 app/module needs to be run under
> the same perl? Any run-time decision based mechanism will probably
> introduce a way too much complexity and run-time overhead for mp2, just to
> support mp1? Or do I miss something?
For $r: wouldn't one "bool needs_compat_layer" variable (struct field?)
per configured handler suffice? That would be one byte and one
comparison (per request, I guess).
For other objects... I'll think about it.
>> Who cares about the C API, since all we need to do is to provide a
>> compatible perl one? Current Apache::compat already does it, the
>> namespace change would just remove the need for calling override_mp2_api.
> Don't forget the overhead of compat implementation too. in the particular
> case of $c->local_addr, it's more efficient for the app to call
> $sockaddr->port, $sockaddr->ip_get if it's running under mp2, then doing
> it in the compat way, where it'll first encode that info into SOCKADDR_IN
> object, just to decode it back a second later? If I were to code an app
> that should be run under both, I'd rather explicitly code it differently
> for each version, which doesn't seem to be possible with your suggested
> case, since mp2 will now return a wrong thing when called even an explicit
> function call like Apache2::Connection($c), since $c will be blessed into
> Apache::Connection. So how do you deal with the situation where you need
> to be able to call real mp2 methods in the environment where things are
> emulated?
Good point. Quick ugly solution:
local_addr => sub {
require Apache2::Connection;
require Socket;
require APR::SockAddr;
my $c = bless shift, 'Apache2::Connection';
my $rval = Socket::pack_sockaddr_in($c->local_addr->port,
Socket::inet_aton($c->local_addr->ip_get));
bless $c, 'Apache::Connection';
return $rval;
},
No idea for something smarter, however. At least right now.
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@stason.org> [21-11-2004 18:39]:
>
>>Radoslaw Zielinski wrote:
>
> [...]
>
>>>Simply: we don't have function foo(), we have methods Apache2::*::foo()
>>>and Apache::*::foo() (the second one introduced by the compat layer).
>>>If the object $c, mentioned in the URL above is blessed to
>>>Apache::Connection (or whatever class it is), $c->local_addr returns a
>>>SOCKADDR_IN object; if it's Apache2::Connection (or whatever), we get
>>>APR::SocketAddr.
>>
>>You should really try to write a test script and you will see that this is
>>impossible. Since Apache2 C API will not give you SOCKADDR_IN, because it
>>doesn't have an API to give you one. Don't write the whole implementation.
>>Just take this particular API local_addr and write a test that will show
>>that you can't have it working both under mp1 and mp2.
>
>
> How do you want me to write a test script without the implementation?
> You mean, an extension to what I attached the last time (trapping use()
> with sub ref in @INC)? Yet it's trivial.
>
> 'Apache/Connection.pm' => [
> 'Apache::Connection',
> '...',
> {
> local_addr => sub {
> require Apache2::Connection;
> require Socket;
> require APR::SockAddr;
> my $c = shift; # is an Apache::Connection object
> my $sockaddr = Apache2::Connection::local_addr($c);
> Socket::pack_sockaddr_in($sockaddr->port,
> Socket::inet_aton($sockaddr->ip_get));
> },
> ...,
> }
> ],
and how do you use that?
If I have the code,
$c->local_addr;
which of the implementations will be invoked? At which point $c gets
blessed into Apache::Connection and not Apache2::Connection? do you
suggest that if the compat layer that you suggest is loaded mp2 should
bless everything ($r, $c, $s, etc.) into Apache::* namespace and not
Apache2::* namespace?
How is this going to work if a real mp2 app/module needs to be run under
the same perl? Any run-time decision based mechanism will probably
introduce a way too much complexity and run-time overhead for mp2, just to
support mp1? Or do I miss something?
> Who cares about the C API, since all we need to do is to provide a
> compatible perl one? Current Apache::compat already does it, the
> namespace change would just remove the need for calling override_mp2_api.
Don't forget the overhead of compat implementation too. in the particular
case of $c->local_addr, it's more efficient for the app to call
$sockaddr->port, $sockaddr->ip_get if it's running under mp2, then doing
it in the compat way, where it'll first encode that info into SOCKADDR_IN
object, just to decode it back a second later? If I were to code an app
that should be run under both, I'd rather explicitly code it differently
for each version, which doesn't seem to be possible with your suggested
case, since mp2 will now return a wrong thing when called even an explicit
function call like Apache2::Connection($c), since $c will be blessed into
Apache::Connection. So how do you deal with the situation where you need
to be able to call real mp2 methods in the environment where things are
emulated?
>>>The trick is in [1].
>>
>>[...]
>>
>>>[1] The problem is to tell mod_perl's internals, that it should return
>>>Apache2::* objects for handlers ported to mp2 and Apache::* for these,
>>>which are not ready. I thought about using a per-<VirtualHost> or
>>><Location> directive in httpd.conf. By objects I mean for example $r,
>>>which PerlHandler::handler() gets as its first argument.
>>
>>modperl internals are either mp1 or mp2, never both at the same time. So
>>mp1 can't return mp2 internals and vice versa.
>
>
> What it returns, is just a variable blessed to a specific class; nothing
> super-magical in it. I don't know how the information about the class
> name is stored in perl internals, but I guess it's possible to change it
> in the run-time (before returning to the handler), as the
> handler_for_mp1_partially_ported_to_mp2::handler() I mentioned in one of
> the previous messages would do.
Please see my question above.
>>I think you are mislead by still believing that it's possible to run
>>both at the same time. And this is not the case. mod_perl gives you
>>the perl API for whatever Apache provides, if Apache doesn't have an
>>API to do something mod_perl neither mod_perl will.
>
>
> Hm, about running both at the same time: I meant running mp2 and mp1
> applications on one mp2-controlled interpreter.
Understood.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [21-11-2004 18:39]:
> Radoslaw Zielinski wrote:
[...]
>> Simply: we don't have function foo(), we have methods Apache2::*::foo()
>> and Apache::*::foo() (the second one introduced by the compat layer).
>> If the object $c, mentioned in the URL above is blessed to
>> Apache::Connection (or whatever class it is), $c->local_addr returns a
>> SOCKADDR_IN object; if it's Apache2::Connection (or whatever), we get
>> APR::SocketAddr.
> You should really try to write a test script and you will see that this is
> impossible. Since Apache2 C API will not give you SOCKADDR_IN, because it
> doesn't have an API to give you one. Don't write the whole implementation.
> Just take this particular API local_addr and write a test that will show
> that you can't have it working both under mp1 and mp2.
How do you want me to write a test script without the implementation?
You mean, an extension to what I attached the last time (trapping use()
with sub ref in @INC)? Yet it's trivial.
'Apache/Connection.pm' => [
'Apache::Connection',
'...',
{
local_addr => sub {
require Apache2::Connection;
require Socket;
require APR::SockAddr;
my $c = shift; # is an Apache::Connection object
my $sockaddr = Apache2::Connection::local_addr($c);
Socket::pack_sockaddr_in($sockaddr->port,
Socket::inet_aton($sockaddr->ip_get));
},
...,
}
],
Who cares about the C API, since all we need to do is to provide a
compatible perl one? Current Apache::compat already does it, the
namespace change would just remove the need for calling override_mp2_api.
>> The trick is in [1].
> [...]
>> [1] The problem is to tell mod_perl's internals, that it should return
>> Apache2::* objects for handlers ported to mp2 and Apache::* for these,
>> which are not ready. I thought about using a per-<VirtualHost> or
>> <Location> directive in httpd.conf. By objects I mean for example $r,
>> which PerlHandler::handler() gets as its first argument.
> modperl internals are either mp1 or mp2, never both at the same time. So
> mp1 can't return mp2 internals and vice versa.
What it returns, is just a variable blessed to a specific class; nothing
super-magical in it. I don't know how the information about the class
name is stored in perl internals, but I guess it's possible to change it
in the run-time (before returning to the handler), as the
handler_for_mp1_partially_ported_to_mp2::handler() I mentioned in one of
the previous messages would do.
> I think you are mislead by still believing that it's possible to run
> both at the same time. And this is not the case. mod_perl gives you
> the perl API for whatever Apache provides, if Apache doesn't have an
> API to do something mod_perl neither mod_perl will.
Hm, about running both at the same time: I meant running mp2 and mp1
applications on one mp2-controlled interpreter.
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@stason.org> [21-11-2004 17:48]:
>
>>Radoslaw Zielinski wrote:
>>
>>>Stas Bekman <st...@stason.org> [19-11-2004 21:51]:
>
> [...]
>
>>>>IMHO, it's a waste of time to try to resolve the namespace issue before
>>>>the API incompability is resolved (which I doubt is possible or shouldn't
>>>>be even attempted)
>>>
>>>Huh? Resolving the namespace issue just removes the API incompatibility
>>>problem, doesn't it?
>>
>>How so? IMHO, it's totally unrelated. If you have a function foo() which
>>under both versions accepts the same amount of arguments, which are
>>totally different, and does a completely different thing and returns
>>different things as explained here:
>>http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
>>how resolving the namespace issue is going to resolve that issue?
>
>
> Simply: we don't have function foo(), we have methods Apache2::*::foo()
> and Apache::*::foo() (the second one introduced by the compat layer).
> If the object $c, mentioned in the URL above is blessed to
> Apache::Connection (or whatever class it is), $c->local_addr returns a
> SOCKADDR_IN object; if it's Apache2::Connection (or whatever), we get
> APR::SocketAddr.
You should really try to write a test script and you will see that this is
impossible. Since Apache2 C API will not give you SOCKADDR_IN, because it
doesn't have an API to give you one. Don't write the whole implementation.
Just take this particular API local_addr and write a test that will show
that you can't have it working both under mp1 and mp2.
> The trick is in [1].
[...]
> [1] The problem is to tell mod_perl's internals, that it should return
> Apache2::* objects for handlers ported to mp2 and Apache::* for these,
> which are not ready. I thought about using a per-<VirtualHost> or
> <Location> directive in httpd.conf. By objects I mean for example $r,
> which PerlHandler::handler() gets as its first argument.
modperl internals are either mp1 or mp2, never both at the same time. So
mp1 can't return mp2 internals and vice versa. I think you are mislead by
still believing that it's possible to run both at the same time. And this
is not the case. mod_perl gives you the perl API for whatever Apache
provides, if Apache doesn't have an API to do something mod_perl neither
mod_perl will.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [21-11-2004 17:48]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <st...@stason.org> [19-11-2004 21:51]:
[...]
>>> IMHO, it's a waste of time to try to resolve the namespace issue before
>>> the API incompability is resolved (which I doubt is possible or shouldn't
>>> be even attempted)
>> Huh? Resolving the namespace issue just removes the API incompatibility
>> problem, doesn't it?
> How so? IMHO, it's totally unrelated. If you have a function foo() which
> under both versions accepts the same amount of arguments, which are
> totally different, and does a completely different thing and returns
> different things as explained here:
> http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
> how resolving the namespace issue is going to resolve that issue?
Simply: we don't have function foo(), we have methods Apache2::*::foo()
and Apache::*::foo() (the second one introduced by the compat layer).
If the object $c, mentioned in the URL above is blessed to
Apache::Connection (or whatever class it is), $c->local_addr returns a
SOCKADDR_IN object; if it's Apache2::Connection (or whatever), we get
APR::SocketAddr.
The trick is in [1].
>>> Have you read the URL quoted above? The two APIs behave totally different
>> Yes, Stas, I have read it. Several times, actually, to make sure
>> I haven't left out any unresolvable issues. I really don't see any.
>> Could you name it?
> Great. So do we agree that there is an issue which is a showstopper for
> the rest of the suggestion? (see above)
No, we don't. As above.
> Moreover there are APIs which don't exist anymore and for some of them
> it's not possible to implement for backword compatibility.
Oh well, then forget them. There is no such thing as a perfect compat
layer.
>>> and it's not possible to figure out at run time, which API generation is
>>> desired.
>> ...I just don't see an easy way to resolve this one right now, if the
>> httpd.conf directive option I mentioned earlier is not acceptable /
>> possible. But I think I'll figure something out.
> sorry, Radoslaw, I'm not sure which directive are you talking about. could
> you please quote the relevant part of your suggestoin?
[1] The problem is to tell mod_perl's internals, that it should return
Apache2::* objects for handlers ported to mp2 and Apache::* for these,
which are not ready. I thought about using a per-<VirtualHost> or
<Location> directive in httpd.conf. By objects I mean for example $r,
which PerlHandler::handler() gets as its first argument.
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@stason.org> [19-11-2004 21:51]:
>
>>Radoslaw Zielinski wrote:
>>
>>>Stas Bekman <st...@stason.org> [14-11-2004 17:05]:
>>>
>>>>Radoslaw Zielinski wrote:
>>>
>>>[...]
>>>
>>>>>>to support this aliasing feature. Or do you suggest to just alias the
>>>>>>namespaces?
>>>>>
>>>>>Maybe I'm missing something. I was thinking about just aliasing the
>>>>>namespaces.
>>>>
>>>>It's a way more complicated than it seems to be at first sight. Search
>>>>the dev list's archives for EazyLife to see some of the problems.
>>>
>>>Done... OK, so AUTOLOAD is just a can of worms.
>>>But, as the code we're trying to make work already knows which
>>>modules does it need to work, we can try a different approach:
>>>trap the "use Apache::OldName" calls with a subroutine ref in @INC.
>>>Example implementation attached; would this work?
>>>I actually don't really like it, as it's a hack, but... I can't see
>>>how this could impact on anything.
>>>Well, let's see what I've missed now ;-)
>>
>>IMHO, it's a waste of time to try to resolve the namespace issue before
>>the API incompability is resolved (which I doubt is possible or shouldn't
>>be even attempted)
>
>
> Huh? Resolving the namespace issue just removes the API incompatibility
> problem, doesn't it?
How so? IMHO, it's totally unrelated. If you have a function foo() which
under both versions accepts the same amount of arguments, which are
totally different, and does a completely different thing and returns
different things as explained here:
http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
how resolving the namespace issue is going to resolve that issue?
>>Have you read the URL quoted above? The two APIs behave totally different
>
>
> Yes, Stas, I have read it. Several times, actually, to make sure
> I haven't left out any unresolvable issues. I really don't see any.
> Could you name it?
Great. So do we agree that there is an issue which is a showstopper for
the rest of the suggestion? (see above)
Moreover there are APIs which don't exist anymore and for some of them
it's not possible to implement for backword compatibility.
>>and it's not possible to figure out at run time, which API generation is
>>desired.
>
>
> ...I just don't see an easy way to resolve this one right now, if the
> httpd.conf directive option I mentioned earlier is not acceptable /
> possible. But I think I'll figure something out.
sorry, Radoslaw, I'm not sure which directive are you talking about. could
you please quote the relevant part of your suggestoin?
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [19-11-2004 21:51]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <st...@stason.org> [14-11-2004 17:05]:
>>> Radoslaw Zielinski wrote:
>> [...]
>>>>> to support this aliasing feature. Or do you suggest to just alias the
>>>>> namespaces?
>>>> Maybe I'm missing something. I was thinking about just aliasing the
>>>> namespaces.
>>> It's a way more complicated than it seems to be at first sight. Search
>>> the dev list's archives for EazyLife to see some of the problems.
>> Done... OK, so AUTOLOAD is just a can of worms.
>> But, as the code we're trying to make work already knows which
>> modules does it need to work, we can try a different approach:
>> trap the "use Apache::OldName" calls with a subroutine ref in @INC.
>> Example implementation attached; would this work?
>> I actually don't really like it, as it's a hack, but... I can't see
>> how this could impact on anything.
>> Well, let's see what I've missed now ;-)
> IMHO, it's a waste of time to try to resolve the namespace issue before
> the API incompability is resolved (which I doubt is possible or shouldn't
> be even attempted)
Huh? Resolving the namespace issue just removes the API incompatibility
problem, doesn't it?
[...]
>>> The problem is that mp1 and mp2 aren't fully compatible, and there is no
>>> way to make them so 100%, mainly. So you have a problem here. You can't
>>> run all mp1 and mp2 applications under the same interpreter. Again take a
>>> look at lib/Apache/compat.pm %overridable_mp2_api and read:
>>> http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
>> I've seen it before and still don't see a problem, when we have *different
>> namespaces*. I assume, that the compatibility layer is similar (in
>> effect, not necessarily the implementation) to the attached one.
>> Can the problem you're seeing be resolved by (I don't know how to do it
>> mod_perl-wide; maybe a per-VirtualHost/Location directive, telling mp2
>> to return objects blessed into a specific namespace for a given handler?):
>> package handler_for_mp1_partially_ported_to_mp2;
>> sub handler {
>> my $r = bless shift, 'Apache::RequestRec'; # was Apache2::RequestRec
>> # same thing with $c or whatever
>> ...
> Have you read the URL quoted above? The two APIs behave totally different
Yes, Stas, I have read it. Several times, actually, to make sure
I haven't left out any unresolvable issues. I really don't see any.
Could you name it?
> and it's not possible to figure out at run time, which API generation is
> desired.
...I just don't see an easy way to resolve this one right now, if the
httpd.conf directive option I mentioned earlier is not acceptable /
possible. But I think I'll figure something out.
> The code you've attached doesn't address that issue and it should be the
> first issue to tackle. The rest is easier.
[...]
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@stason.org> [14-11-2004 17:05]:
>
>>Radoslaw Zielinski wrote:
>
> [...]
>
>>>>to support this aliasing feature. Or do you suggest to just alias the
>>>>namespaces?
>>>
>>>Maybe I'm missing something. I was thinking about just aliasing the
>>>namespaces.
>>
>>It's a way more complicated than it seems to be at first sight. Search the
>>dev list's archives for EazyLife to see some of the problems.
>
>
> Done... OK, so AUTOLOAD is just a can of worms.
>
> But, as the code we're trying to make work already knows which
> modules does it need to work, we can try a different approach:
> trap the "use Apache::OldName" calls with a subroutine ref in @INC.
> Example implementation attached; would this work?
>
> I actually don't really like it, as it's a hack, but... I can't see
> how this could impact on anything.
>
> Well, let's see what I've missed now ;-)
IMHO, it's a waste of time to try to resolve the namespace issue before
the API incompability is resolved (which I doubt is possible or shouldn't
be even attempted)
>>>>Second, quite a few methods have the same API name, but a totally
>>>>different functionality. Please see lib/Apache/compat.pm starting from
>>>>overridable_mp2_api.
>>>>I can't see how the two can coexist.
>>>
>>> $ cat MP2/Foo.pm
>>> package MP2::Foo;
>>> sub sf { print shift() . "::same\n"; }
>>> sub df { print shift() . "::different\n"; }
>>> 1;
>>
>>[...]
>>
>>>...well, maybe in a smarter way. Note, that this allows coexistence of
>>>both mp1 and mp2 applications in one interpreter.
>>
>>The problem is that mp1 and mp2 aren't fully compatible, and there is no
>>way to make them so 100%, mainly. So you have a problem here. You can't
>>run all mp1 and mp2 applications under the same interpreter. Again take a
>>look at lib/Apache/compat.pm %overridable_mp2_api and read:
>>http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
>
>
> I've seen it before and still don't see a problem, when we have *different
> namespaces*. I assume, that the compatibility layer is similar (in
> effect, not necessarily the implementation) to the attached one.
>
> Can the problem you're seeing be resolved by (I don't know how to do it
> mod_perl-wide; maybe a per-VirtualHost/Location directive, telling mp2
> to return objects blessed into a specific namespace for a given handler?):
>
> package handler_for_mp1_partially_ported_to_mp2;
> sub handler {
> my $r = bless shift, 'Apache::RequestRec'; # was Apache2::RequestRec
> # same thing with $c or whatever
> ...
> }
Have you read the URL quoted above? The two APIs behave totally different
and it's not possible to figure out at run time, which API generation is
desired.
The code you've attached doesn't address that issue and it should be the
first issue to tackle. The rest is easier.
>>I think I've mentioned this already, I'm not disagreeing with you,
>>Radoslaw, that I've wished there was a better way than what we have now.
>>But if you really start implementing your proposal you will see that there
>>are problems in your idea. And some of them might be the showstopper. You
>>are more than welcome to prove me/us wrong with a concrete working code.
>
>
> Are you saying that this namespace change could -- if implemented --
> still get to mp2?
I don't know why nobody else seems to care and joins our conversation, but
anything can be changed before 2.0.0 is released, if there is a good
reason for it.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [14-11-2004 17:05]:
> Radoslaw Zielinski wrote:
[...]
>>> to support this aliasing feature. Or do you suggest to just alias the
>>> namespaces?
>> Maybe I'm missing something. I was thinking about just aliasing the
>> namespaces.
> It's a way more complicated than it seems to be at first sight. Search the
> dev list's archives for EazyLife to see some of the problems.
Done... OK, so AUTOLOAD is just a can of worms.
But, as the code we're trying to make work already knows which
modules does it need to work, we can try a different approach:
trap the "use Apache::OldName" calls with a subroutine ref in @INC.
Example implementation attached; would this work?
I actually don't really like it, as it's a hack, but... I can't see
how this could impact on anything.
Well, let's see what I've missed now ;-)
>>> Second, quite a few methods have the same API name, but a totally
>>> different functionality. Please see lib/Apache/compat.pm starting from
>>> overridable_mp2_api.
>>> I can't see how the two can coexist.
>> $ cat MP2/Foo.pm
>> package MP2::Foo;
>> sub sf { print shift() . "::same\n"; }
>> sub df { print shift() . "::different\n"; }
>> 1;
> [...]
>> ...well, maybe in a smarter way. Note, that this allows coexistence of
>> both mp1 and mp2 applications in one interpreter.
> The problem is that mp1 and mp2 aren't fully compatible, and there is no
> way to make them so 100%, mainly. So you have a problem here. You can't
> run all mp1 and mp2 applications under the same interpreter. Again take a
> look at lib/Apache/compat.pm %overridable_mp2_api and read:
> http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
I've seen it before and still don't see a problem, when we have *different
namespaces*. I assume, that the compatibility layer is similar (in
effect, not necessarily the implementation) to the attached one.
Can the problem you're seeing be resolved by (I don't know how to do it
mod_perl-wide; maybe a per-VirtualHost/Location directive, telling mp2
to return objects blessed into a specific namespace for a given handler?):
package handler_for_mp1_partially_ported_to_mp2;
sub handler {
my $r = bless shift, 'Apache::RequestRec'; # was Apache2::RequestRec
# same thing with $c or whatever
...
}
> I think I've mentioned this already, I'm not disagreeing with you,
> Radoslaw, that I've wished there was a better way than what we have now.
> But if you really start implementing your proposal you will see that there
> are problems in your idea. And some of them might be the showstopper. You
> are more than welcome to prove me/us wrong with a concrete working code.
Are you saying that this namespace change could -- if implemented --
still get to mp2?
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Sorry for the delay, I couldn't make it sooner.
>
> Stas Bekman <st...@stason.org> [03-11-2004 02:30]:
>
>>Radoslaw Zielinski wrote:
>
> [...]
>
>>>* It messes with @INC, changing the way it should be parsed.
>>> Originally, if you see $inc_file/Foo/Bar/Baz.pm, you know it's the
>>> Foo::Bar::Baz perl module. Now, it's Foo::Bar::Baz *unless* Foo
>>> equals to Apache2. The only other module I know, which does it, is
>>> Tk; it creates problems with automated dependency generators (at
>>> least), besides being a hack.
>>
>>it doesn't.
>
>
> Well, it (the MP_INST_APACHE2 hack) does: "use Apache2" adds an entry to
> @INC and other modules rely on it.
When saying "it doesn't" I was talking about the para below:
>>There is no Apache2::Apache::Server. There is Apache::Server.
>>It's just one Apache2/ subdir (like there are many other special subdirs
>>in @INC dirs). Shouldn't be too hard to get used to it.
>
>
> I don't know of any more but Tk's plugin directory.
Think user-installed local modules under ~foo/lib/perl
>>This whole issue is moot for users who have moved to mp2 and forgot that
>>mp1 ever existed, which will be the case for 99% of users some time after
>>2.0 is released and considered stable.
>
>
> And what should an average Joe Distributor do while both versions are in
> use...?
Good point. In which case mp2 will always have to go to Apache2/.
>>>* A sysadmin (or user) without Perl knowledge won't even be able to
>>> build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for
>>> example), when an installation of mp1 already exists -- requires
>>> ripping Makefile.PL with sharpened $EDITOR. Yes, this Makefile.PL
>>> can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one
>>> of many.
>>
>>I'm not following you on this one. What's the problem of passing
>>MP_INST_APACHE2=1? You mean they actually need to know that they need to
>>type that? But the error message tells them that already.
>
>
> No. Maybe a "patch" will show it:
>
> --- mod_perl-1.99_15-org/Makefile.PL 2004-08-24 18:33:21.035839248 +0200
> +++ mod_perl-1.99_13/Makefile.PL 2004-08-24 18:34:24.406205488 +0200
> @@ -151,7 +151,7 @@
> error "cannot install mod_perl/$VERSION on top of $vstring",
> "use MP_INST_APACHE2=1 option " .
> "or to force installation delete:\n $old_modperl_pm";
> - exit 1;
> +# exit 1;
> }
> }
> }
>
> I want to build without MP_INST_APACHE2 and run make install with
> DESTDIR. This is a minor example of problems with "Makefile.PL logic".
> Nevermind.
Good point again. We should support that. i.e. if DESTDIR is specified we
shouldn't enforce MP_INST_APACHE2=1 unless we find mod_perl 1 installed at
that DESTDIR.
>>There are quite a few CPAN modules that deploy that technique. e.g.
>>Apache-VMonitor-2.0.
>
>
> It uses a 5KB Makefile.PL just for figuring the installation path and
> dependencies... :-/
True. My idea was to write a helper module and make it available on CPAN,
so all other 3rd party modules can use that and have very simple
Makefile.PL files. Notice that it also requires special arguments passed
to Makefile.PL to handle the situation when both mp1 and mp2 are
installed. So if the same API is not embraced by all other 3rd party
modules it's going to be a pain.
>>>Full Apache2::* namespace. Apache2::compat::Apache1 could provide
>>>Apache::*->Apache2::* aliases for compatible features and define custom
>>>Apache::* for the incompatible ones -- both types of applications could
>>>work in one interpreter. That would leave place for A2::compat::A3, and
>>>maybe for Apache::compat::Apache2. No hacks required.
>>
>>If you dig under the hood, it's not simple at all. To start with how are
>>you going to handle the fact that no module is loaded by default? And you
>>certainly don't want to load 50 modules each coming with .so object, just
>
> [1]
>
>>to support this aliasing feature. Or do you suggest to just alias the
>>namespaces?
>
>
> Maybe I'm missing something. I was thinking about just aliasing the
> namespaces.
It's a way more complicated than it seems to be at first sight. Search the
dev list's archives for EazyLife to see some of the problems.
>>Second, quite a few methods have the same API name, but a totally
>>different functionality. Please see lib/Apache/compat.pm starting from
>>overridable_mp2_api.
>
>
>>I can't see how the two can coexist.
>
>
> $ cat MP2/Foo.pm
> package MP2::Foo;
> sub sf { print shift() . "::same\n"; }
> sub df { print shift() . "::different\n"; }
> 1;
[...]
> ...well, maybe in a smarter way. Note, that this allows coexistence of
> both mp1 and mp2 applications in one interpreter.
The problem is that mp1 and mp2 aren't fully compatible, and there is no
way to make them so 100%, mainly. So you have a problem here. You can't
run all mp1 and mp2 applications under the same interpreter. Again take a
look at lib/Apache/compat.pm %overridable_mp2_api and read:
http://perl.apache.org/docs/2.0/api/Apache/compat.html#Compatibility_Functions_Colliding_with_mod_perl_2_0_API
I think I've mentioned this already, I'm not disagreeing with you,
Radoslaw, that I've wished there was a better way than what we have now.
But if you really start implementing your proposal you will see that there
are problems in your idea. And some of them might be the showstopper. You
are more than welcome to prove me/us wrong with a concrete working code.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Sorry for the delay, I couldn't make it sooner.
Stas Bekman <st...@stason.org> [03-11-2004 02:30]:
> Radoslaw Zielinski wrote:
[...]
>> * It messes with @INC, changing the way it should be parsed.
>> Originally, if you see $inc_file/Foo/Bar/Baz.pm, you know it's the
>> Foo::Bar::Baz perl module. Now, it's Foo::Bar::Baz *unless* Foo
>> equals to Apache2. The only other module I know, which does it, is
>> Tk; it creates problems with automated dependency generators (at
>> least), besides being a hack.
> it doesn't.
Well, it (the MP_INST_APACHE2 hack) does: "use Apache2" adds an entry to
@INC and other modules rely on it.
> There is no Apache2::Apache::Server. There is Apache::Server.
> It's just one Apache2/ subdir (like there are many other special subdirs
> in @INC dirs). Shouldn't be too hard to get used to it.
I don't know of any more but Tk's plugin directory.
>> * If the API wouldn't change, there would be no porting problems. Even
>> if mp2 is mostly backward-compatible, mp1 isn't forward-compatible; is
>> it? Now, there is no easy (automateable) way of discovering if the
>> module works with mp1 or mp2, or for which version it was written for.
> 1) It should be documented.
> 2) It should be enforced at compile/run time.
In a perfect case. But -- from my expirience -- it rarely is.
[...]
>> * "use Apache2" isn't mandatory, so (IIRC, when I checked last time)
>> most of the mp-dependent code doesn't do it. To patch, or not to
>> patch? To care, or to drop&forget?
> I know. I agree with that point. We have discussed that one quite a lot of
> time. To sum up those discussions, the reason we don't load it
> automatically is to let users adjust their @INC, before Apache2 is loaded.
> Which is a must in case a user has a local modules installation and has
> mod_perl2 living there.
> This whole issue is moot for users who have moved to mp2 and forgot that
> mp1 ever existed, which will be the case for 99% of users some time after
> 2.0 is released and considered stable.
And what should an average Joe Distributor do while both versions are in
use...?
>> * A sysadmin (or user) without Perl knowledge won't even be able to
>> build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for
>> example), when an installation of mp1 already exists -- requires
>> ripping Makefile.PL with sharpened $EDITOR. Yes, this Makefile.PL
>> can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one
>> of many.
> I'm not following you on this one. What's the problem of passing
> MP_INST_APACHE2=1? You mean they actually need to know that they need to
> type that? But the error message tells them that already.
No. Maybe a "patch" will show it:
--- mod_perl-1.99_15-org/Makefile.PL 2004-08-24 18:33:21.035839248 +0200
+++ mod_perl-1.99_13/Makefile.PL 2004-08-24 18:34:24.406205488 +0200
@@ -151,7 +151,7 @@
error "cannot install mod_perl/$VERSION on top of $vstring",
"use MP_INST_APACHE2=1 option " .
"or to force installation delete:\n $old_modperl_pm";
- exit 1;
+# exit 1;
}
}
}
I want to build without MP_INST_APACHE2 and run make install with
DESTDIR. This is a minor example of problems with "Makefile.PL logic".
Nevermind.
>> * Doug wrote: "xs modules will need Makefile.PL/#ifdef logic to work
>> with both versions". Well, from my expirience, if such a logic works
>> in any not-so-weird case and doesn't require investigation / patching,
>> it's accidental. If you want both mp1 and mp2 on your system, you
>> won't get away without all-the-hacks' know-how.
> From my personal experience, I have separate XS files for each version.
> See Apache::Peek. I don't think it's a good idea to try to support both
> versions in the same XS file. The C API is *totally* different between the
> two generations.
I don't have any XS knowledge, so just guess it would be possible to
write separate "plugins" for both versions (if one wants to support
both).
[...]
>> All these issues boil down to one thing: you can't have mp1 and mp2 with
>> applications for both without using hacks. You aimed for simplicity and
>> backward compatibility, but IMHO the result was reversed in this case.
> Either we are not on the same line or I'm not agreeing with you.
I think the first one. We can eventually come back to it later.
> There are quite a few CPAN modules that deploy that technique. e.g.
> Apache-VMonitor-2.0.
It uses a 5KB Makefile.PL just for figuring the installation path and
dependencies... :-/
> Granted, there are issues with making the process of choosing the right
> generation (for those who have both installed) at build time. My hope
> was/is to have one standard way to handle that.
IMHO sooner mp1 will vanish.
>> How could it be avoided?
>> Full Apache2::* namespace. Apache2::compat::Apache1 could provide
>> Apache::*->Apache2::* aliases for compatible features and define custom
>> Apache::* for the incompatible ones -- both types of applications could
>> work in one interpreter. That would leave place for A2::compat::A3, and
>> maybe for Apache::compat::Apache2. No hacks required.
> If you dig under the hood, it's not simple at all. To start with how are
> you going to handle the fact that no module is loaded by default? And you
> certainly don't want to load 50 modules each coming with .so object, just
[1]
> to support this aliasing feature. Or do you suggest to just alias the
> namespaces?
Maybe I'm missing something. I was thinking about just aliasing the
namespaces.
> Second, quite a few methods have the same API name, but a totally
> different functionality. Please see lib/Apache/compat.pm starting from
> overridable_mp2_api.
> I can't see how the two can coexist.
$ cat MP2/Foo.pm
package MP2::Foo;
sub sf { print shift() . "::same\n"; }
sub df { print shift() . "::different\n"; }
1;
$ cat MP2/compat1.pm
package MP2::compat1;
use MP2::Foo;
BEGIN { $INC{'MP1/Foo.pm'} = __FILE__; }
*MP1::Foo::df = sub { print shift() . "::different_overridden\n"; };
*MP1::Foo::sf = \&MP2::Foo::sf;
1;
$ perl -MMP2::compat1 -MMP1::Foo -we 'MP1::Foo->sf; MP1::Foo->df'
MP1::Foo::same
MP1::Foo::different_overridden
About [1]: if there is too many MP2::Foo's to use() them in MP2::compat1,
then maybe AutoLoader could help:
$ cat MP2/compat1.pm
package MP2::compat1;
use AutoLoader ();
BEGIN { $INC{'MP1/Foo.pm'} = __FILE__; }
*MP1::Foo::AUTOLOAD = \&MP2::compat1::autoload;
sub autoload {
($AUTOLOAD =~ /^MP1::((.+)::.+)$/)
? eval "require MP2::$2"
: die "you murderer, I didn't got here by accident";
die $@ if $@;
*MP1::Foo::df = sub { print shift() . "::different_overridden\n"; };
*MP1::Foo::sf = \&MP2::Foo::sf;
# other aliases go here... this should only be executed once
goto &$AUTOLOAD;
}
1;
...well, maybe in a smarter way. Note, that this allows coexistence of
both mp1 and mp2 applications in one interpreter.
[...]
> One more thing to consider. At the moment 3rd party modules will be
> installed into Apache2/ if mp2 lives there. so if your proposal goes in,
> that means that all CPAN modules will need to have Apache2/ for the mp2
> implementation (in case there are two separate implementations) again
> requiring a compat layer in the case where the user API of those CPAN
> modules (not modperl) hasn't changed).
I think this price is worth the cleaner interface and less hackish
approach.
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
[...]
> ...but now I did some homework, and -- suprisingly -- you knew them:
> <http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99075968309515&w=2>.
> Then Doug came up with the hackish approach:
> <http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99076168913061&w=2>.
>
> Now why is it wrong?
>
> * It relies upon changed @INC. Another thing to be remembered about.
> * It messes with @INC, changing the way it should be parsed.
> Originally, if you see $inc_file/Foo/Bar/Baz.pm, you know it's the
> Foo::Bar::Baz perl module. Now, it's Foo::Bar::Baz *unless* Foo
> equals to Apache2. The only other module I know, which does it, is
> Tk; it creates problems with automated dependency generators (at
> least), besides being a hack.
it doesn't. There is no Apache2::Apache::Server. There is Apache::Server.
It's just one Apache2/ subdir (like there are many other special subdirs
in @INC dirs). Shouldn't be too hard to get used to it.
> * If the API wouldn't change, there would be no porting problems. Even
> if mp2 is mostly backward-compatible, mp1 isn't forward-compatible; is
> it? Now, there is no easy (automateable) way of discovering if the
> module works with mp1 or mp2, or for which version it was written for.
1) It should be documented.
2) It should be enforced at compile/run time.
> * You can't use both mp1 and mp2 applications in scope of a single
> "PerlModule Apache::compat" (if the mp2 application is Apache::compat
> incompatible).
And you certainly shouldn't do that, if I understood correctly what you
have meant.
> * "use Apache2" isn't mandatory, so (IIRC, when I checked last time)
> most of the mp-dependent code doesn't do it. To patch, or not to
> patch? To care, or to drop&forget?
I know. I agree with that point. We have discussed that one quite a lot of
time. To sum up those discussions, the reason we don't load it
automatically is to let users adjust their @INC, before Apache2 is loaded.
Which is a must in case a user has a local modules installation and has
mod_perl2 living there.
This whole issue is moot for users who have moved to mp2 and forgot that
mp1 ever existed, which will be the case for 99% of users some time after
2.0 is released and considered stable.
> * A sysadmin (or user) without Perl knowledge won't even be able to
> build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for
> example), when an installation of mp1 already exists -- requires
> ripping Makefile.PL with sharpened $EDITOR. Yes, this Makefile.PL
> can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one
> of many.
I'm not following you on this one. What's the problem of passing
MP_INST_APACHE2=1? You mean they actually need to know that they need to
type that? But the error message tells them that already.
> * Doug wrote: "xs modules will need Makefile.PL/#ifdef logic to work
> with both versions". Well, from my expirience, if such a logic works
> in any not-so-weird case and doesn't require investigation / patching,
> it's accidental. If you want both mp1 and mp2 on your system, you
> won't get away without all-the-hacks' know-how.
From my personal experience, I have separate XS files for each version.
See Apache::Peek. I don't think it's a good idea to try to support both
versions in the same XS file. The C API is *totally* different between the
two generations.
> * ...well, I don't remember more right now.
>
> All these issues boil down to one thing: you can't have mp1 and mp2 with
> applications for both without using hacks. You aimed for simplicity and
> backward compatibility, but IMHO the result was reversed in this case.
Either we are not on the same line or I'm not agreeing with you. There are
quite a few CPAN modules that deploy that technique. e.g. Apache-VMonitor-2.0.
Granted, there are issues with making the process of choosing the right
generation (for those who have both installed) at build time. My hope
was/is to have one standard way to handle that.
> How could it be avoided?
>
> Full Apache2::* namespace. Apache2::compat::Apache1 could provide
> Apache::*->Apache2::* aliases for compatible features and define custom
> Apache::* for the incompatible ones -- both types of applications could
> work in one interpreter. That would leave place for A2::compat::A3, and
> maybe for Apache::compat::Apache2. No hacks required.
If you dig under the hood, it's not simple at all. To start with how are
you going to handle the fact that no module is loaded by default? And you
certainly don't want to load 50 modules each coming with .so object, just
to support this aliasing feature. Or do you suggest to just alias the
namespaces?
Second, quite a few methods have the same API name, but a totally
different functionality. Please see lib/Apache/compat.pm starting from
overridable_mp2_api.
I can't see how the two can coexist.
> About the [1] mess: I don't see any. If you'd like your application to
> work with both, you'd write for mp1 and require the appropiate compat
> module to be loaded. If something's missing, we'll see it at the
> compilation stage, without wondering "does this method I'm using in this
> rarely triggered case do the same thing under mp2 with Apache::compat?".
unfortunately there is no compat module which handles everything. some
parts aren't feasible (e.g. see my above comment wrt to overridable_mp2_api.
> I just hope I don't repeat something already discussed.
I don't recall this idea being mentioned. So it's probably a new one.
Please correct me if I'm wrong.
One more thing to consider. At the moment 3rd party modules will be
installed into Apache2/ if mp2 lives there. so if your proposal goes in,
that means that all CPAN modules will need to have Apache2/ for the mp2
implementation (in case there are two separate implementations) again
requiring a compat layer in the case where the user API of those CPAN
modules (not modperl) hasn't changed).
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [02-11-2004 05:59]:
> Radoslaw Zielinski wrote:
[...]
>> Sorry for warming up old threads, but I think it's worth to be noted: if
>> the two versions are incompatible, the proper solution is a namespace
>> change; in this case: APR2::* hierarchy.
>> A pity it hasn't been done with Apache::* modules, the MP_INST_APACHE2 +
>> "use Apache2" hack is a real pain in the ass for the distributors (like
>> Linux distributions).
> As it was repeated many times here (my apologies if it's the first time
> that you hear that), the reason for not embedding the version number in
> the module name is because for most the user API doesn't change. So if
> your module/app wants to support several generations of some other module,
> whose API hasn't changed, you don't need to turn your code into a big mess.
-> [1]
> talking to myself: I think I should add this to the docs somewhere. I've
> repeated that explanation quite a few times already.
Well, this explanation was quite obvious for me, so I didn't even check
the archives -- explaining why something is a PITA doesn't make it less
painful. I thought that you introduced it without forseeing the future
drawbacks...
> Radoslaw, please grep the archives for Apache2 (I believe) to find the
> relevant threads (there were quite a few of those on both lists).
...but now I did some homework, and -- suprisingly -- you knew them:
<http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99075968309515&w=2>.
Then Doug came up with the hackish approach:
<http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99076168913061&w=2>.
Now why is it wrong?
* It relies upon changed @INC. Another thing to be remembered about.
* It messes with @INC, changing the way it should be parsed.
Originally, if you see $inc_file/Foo/Bar/Baz.pm, you know it's the
Foo::Bar::Baz perl module. Now, it's Foo::Bar::Baz *unless* Foo
equals to Apache2. The only other module I know, which does it, is
Tk; it creates problems with automated dependency generators (at
least), besides being a hack.
* If the API wouldn't change, there would be no porting problems. Even
if mp2 is mostly backward-compatible, mp1 isn't forward-compatible; is
it? Now, there is no easy (automateable) way of discovering if the
module works with mp1 or mp2, or for which version it was written for.
* You can't use both mp1 and mp2 applications in scope of a single
"PerlModule Apache::compat" (if the mp2 application is Apache::compat
incompatible).
* "use Apache2" isn't mandatory, so (IIRC, when I checked last time)
most of the mp-dependent code doesn't do it. To patch, or not to
patch? To care, or to drop&forget?
* A sysadmin (or user) without Perl knowledge won't even be able to
build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for
example), when an installation of mp1 already exists -- requires
ripping Makefile.PL with sharpened $EDITOR. Yes, this Makefile.PL
can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one
of many.
* Doug wrote: "xs modules will need Makefile.PL/#ifdef logic to work
with both versions". Well, from my expirience, if such a logic works
in any not-so-weird case and doesn't require investigation / patching,
it's accidental. If you want both mp1 and mp2 on your system, you
won't get away without all-the-hacks' know-how.
* ...well, I don't remember more right now.
All these issues boil down to one thing: you can't have mp1 and mp2 with
applications for both without using hacks. You aimed for simplicity and
backward compatibility, but IMHO the result was reversed in this case.
How could it be avoided?
Full Apache2::* namespace. Apache2::compat::Apache1 could provide
Apache::*->Apache2::* aliases for compatible features and define custom
Apache::* for the incompatible ones -- both types of applications could
work in one interpreter. That would leave place for A2::compat::A3, and
maybe for Apache::compat::Apache2. No hacks required.
About the [1] mess: I don't see any. If you'd like your application to
work with both, you'd write for mp1 and require the appropiate compat
module to be loaded. If something's missing, we'll see it at the
compilation stage, without wondering "does this method I'm using in this
rarely triggered case do the same thing under mp2 with Apache::compat?".
I just hope I don't repeat something already discussed.
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Radoslaw Zielinski wrote:
> Stas Bekman <st...@stason.org> [02-07-2004 01:21]:
> [...]
>
>>Though let's think about the future now. What happens when APR 2 is
>>released (currently we have APR 1, don't confuse with Apache 2.x). How do
>>we ensure that several APR generations can co-exist under the same perl
>>install?
>
> [...]
Doh! Radoslaw, thanks for reminding me of this thread [1], where we have
reached the opposite conclusion (not to drop Apache2/ prefix)
> Sorry for warming up old threads, but I think it's worth to be noted: if
> the two versions are incompatible, the proper solution is a namespace
> change; in this case: APR2::* hierarchy.
>
> A pity it hasn't been done with Apache::* modules, the MP_INST_APACHE2 +
> "use Apache2" hack is a real pain in the ass for the distributors (like
> Linux distributions).
As it was repeated many times here (my apologies if it's the first time
that you hear that), the reason for not embedding the version number in
the module name is because for most the user API doesn't change. So if
your module/app wants to support several generations of some other module,
whose API hasn't changed, you don't need to turn your code into a big mess.
talking to myself: I think I should add this to the docs somewhere. I've
repeated that explanation quite a few times already.
Radoslaw, please grep the archives for Apache2 (I believe) to find the
relevant threads (there were quite a few of those on both lists).
[1] http://marc.theaimsgroup.com/?t=108872427200001&r=1&w=2
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Stas Bekman <st...@stason.org> [02-07-2004 01:21]:
[...]
> Though let's think about the future now. What happens when APR 2 is
> released (currently we have APR 1, don't confuse with Apache 2.x). How do
> we ensure that several APR generations can co-exist under the same perl
> install?
[...]
Sorry for warming up old threads, but I think it's worth to be noted: if
the two versions are incompatible, the proper solution is a namespace
change; in this case: APR2::* hierarchy.
A pity it hasn't been done with Apache::* modules, the MP_INST_APACHE2 +
"use Apache2" hack is a real pain in the ass for the distributors (like
Linux distributions).
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>I don't think I'm going to even start with that now, unless someone
>>beats me to it, I'm back to work on finishing the API. As this issue
>>doesn't affect the API it can wait.
>
>
> +1. Maybe mention it in the todo list, in case someone
> wants to scratch that itch later on :-).
Yup, I did that already :)
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> I don't think I'm going to even start with that now, unless someone
> beats me to it, I'm back to work on finishing the API. As this issue
> doesn't affect the API it can wait.
+1. Maybe mention it in the todo list, in case someone
wants to scratch that itch later on :-).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
>>What really needs to happen is to make the $pool object (or the temp)
>>be tied to the object it belongs to ($apreq, $r, etc) and
>>automatically get its refcount to 0 when the corresponding parent
>>object goes out of scope. Which I suppose can be done with a simple
>>DESTROY method. So when we accept the pool object we bump up its ref
>>count and when DESTROY is called it'll decrement this count (this is
>>because there could be more than one object using the same pool).
>>
>>I saw your commit -- if I understand it correctly, you try to make it
>>dependent on the parent, so it won't get its refcount to 0 before the
>>parent go away, right?
>
>
> Correct. It's exactly like doing this:
>
> package Mine;
> sub new {
> my ($class, $parent) = @_;
> bless { my_stuff=> "blah", my_parent => $parent}, $class;
> }
Right, nice! May be you want to document why you did so, so others can grok
your code too. Doug wrote lots of really tricky code and hardly left any
comments, leaving us wondering about what certain chunks of code do, leading
to a lot of wasted time.
> except that in apreq2 I stuffed the parent into a previously unused
> SvMAGIC slot. I think the same plan will work for APR:: objects that need
> a pool for their construction (in fact I'm wondering if all the WrapXS
> machinery can't be put to use for this).
I'm not sure what's more effective:
- attaching magic (no extra code required to cleanup)
- incrementing the pool obj refcount on entry and provide DESTROY to decrement
it (though one needs to stash that obj somewhere)
- tag the pool (as APR::Pool does internally)
Thought don't forget that this is all complicated by the ability of Apache to
destroy the pool, w/o notifying the object. Though APR::Pool should take care
of handling that.
I don't think I'm going to even start with that now, unless someone beats me
to it, I'm back to work on finishing the API. As this issue doesn't affect the
API it can wait.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Scope of pools is a tricky thing. So all the APIs relying on a user
> providing the pool explicitly are potentially problematic at the moment.
+1.
[...more late night gibberish from me...]
> > Here somebody would need to call APR::Pool->DESTROY
> > to actually relinquish the last pool.
>
> Only the last one? I'm not quite sure how are you going to clean up
> the pool of pools. How do you know that you pop the right pool?
Sorry, please forget it- my "flyweight" suggestion makes no
sense whatsoever for this problem.
> What really needs to happen is to make the $pool object (or the temp)
> be tied to the object it belongs to ($apreq, $r, etc) and
> automatically get its refcount to 0 when the corresponding parent
> object goes out of scope. Which I suppose can be done with a simple
> DESTROY method. So when we accept the pool object we bump up its ref
> count and when DESTROY is called it'll decrement this count (this is
> because there could be more than one object using the same pool).
>
> I saw your commit -- if I understand it correctly, you try to make it
> dependent on the parent, so it won't get its refcount to 0 before the
> parent go away, right?
Correct. It's exactly like doing this:
package Mine;
sub new {
my ($class, $parent) = @_;
bless { my_stuff=> "blah", my_parent => $parent}, $class;
}
except that in apreq2 I stuffed the parent into a previously unused
SvMAGIC slot. I think the same plan will work for APR:: objects that need
a pool for their construction (in fact I'm wondering if all the WrapXS
machinery can't be put to use for this).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>There are going to be various tricky bugs to figure out with the new
>>things. I just had one when I tried:
>>
>>perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; open my $fh, "<:APR",
>>"/tmp/xxx", APR::Pool->new; print <$fh>'
>>APR::PerlIO::read: (9) Bad file descriptor at -e line ...
>>
>>it took me time to figure out that the pool has gone out of scope and
>>was destroyed by the time read was attempted.
>
>
> Yup- it took me a few reads to even understand the problem
> you had :-).
:)
Scope of pools is a tricky thing. So all the APIs relying on a user providing
the pool explicitly are potentially problematic at the moment.
>>This fixed the problem:
>>
>>perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; my $p =
>>APR::Pool->new; open my $fh, "<:APR", "/tmp/xxx", $p; print <$fh>'
>>
>>tricky. We may need to have much more defending code if we don't want
>>to get a rain of bug reports. And writing it is not trivial at all :(
>>
>>so in the case of open() we probably need to increment the refcount
>>of the pool object and decrement it on close and hope that we don't
>>get a leak anywhere.
>
>
> The problem is the same for any pool-derived object,
> e.g.
>
> #! perl
> use Apache2;
> use APR::Pool;
> use Apache::Request;
> my $req = Apache::Request->new(APR::Pool->new);
> print $req->param; #KaBoom!
>
> In apreq we don't currently tag the pool SV that constructed us,
> so a DESTROY method can't decrement it. We could change that in
> apreq2,but doing that throughout mp2 might be messy.
It'd be nice to have a common way to do that. Making this manually for each
object is going to be a big mess and error-prone.
> Is it possible to do something within APR::Pool
> to address this? Maybe calling APR::Pool->new()
> can dish out pool objects from an internal list:
>
> package APR::Pool;
> sub new {
> my $parent = shift;
> if (!ref $parent) {
> my $pool = <new APR::Pool object>;
> push @INTERNAL_POOL_LIST, $pool;
> return $pool;
> }
> ...
>
> sub DESTROY {
> my $pool = shift;
> if (!ref $pool) {
> pop @INTERNAL_POOL_LIST;
> }
> }
> Here somebody would need to call APR::Pool->DESTROY
> to actually relinquish the last pool.
Only the last one? I'm not quite sure how are you going to clean up the pool
of pools. How do you know that you pop the right pool?
What really needs to happen is to make the $pool object (or the temp) be tied
to the object it belongs to ($apreq, $r, etc) and automatically get its
refcount to 0 when the corresponding parent object goes out of scope. Which I
suppose can be done with a simple DESTROY method. So when we accept the pool
object we bump up its ref count and when DESTROY is called it'll decrement
this count (this is because there could be more than one object using the same
pool).
I saw your commit -- if I understand it correctly, you try to make it
dependent on the parent, so it won't get its refcount to 0 before the parent
go away, right?
> Conway's OOP
> book discusses the "flyweight pattern", which probably
> has much better ideas than this.
It has been ages since I've read it, so I don't remember much of the neat
tricks Damian gave there.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> There are going to be various tricky bugs to figure out with the new
> things. I just had one when I tried:
>
> perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; open my $fh, "<:APR",
> "/tmp/xxx", APR::Pool->new; print <$fh>'
> APR::PerlIO::read: (9) Bad file descriptor at -e line ...
>
> it took me time to figure out that the pool has gone out of scope and
> was destroyed by the time read was attempted.
Yup- it took me a few reads to even understand the problem
you had :-).
> This fixed the problem:
>
> perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; my $p =
> APR::Pool->new; open my $fh, "<:APR", "/tmp/xxx", $p; print <$fh>'
>
> tricky. We may need to have much more defending code if we don't want
> to get a rain of bug reports. And writing it is not trivial at all :(
>
> so in the case of open() we probably need to increment the refcount
> of the pool object and decrement it on close and hope that we don't
> get a leak anywhere.
The problem is the same for any pool-derived object,
e.g.
#! perl
use Apache2;
use APR::Pool;
use Apache::Request;
my $req = Apache::Request->new(APR::Pool->new);
print $req->param; #KaBoom!
In apreq we don't currently tag the pool SV that constructed us,
so a DESTROY method can't decrement it. We could change that in
apreq2,but doing that throughout mp2 might be messy.
Is it possible to do something within APR::Pool
to address this? Maybe calling APR::Pool->new()
can dish out pool objects from an internal list:
package APR::Pool;
sub new {
my $parent = shift;
if (!ref $parent) {
my $pool = <new APR::Pool object>;
push @INTERNAL_POOL_LIST, $pool;
return $pool;
}
...
sub DESTROY {
my $pool = shift;
if (!ref $pool) {
pop @INTERNAL_POOL_LIST;
}
}
Here somebody would need to call APR::Pool->DESTROY
to actually relinquish the last pool. Conway's OOP
book discusses the "flyweight pattern", which probably
has much better ideas than this.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [apr] dropping Apache2/ subdir for APR::*
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>Of course for this to happen we need more hands to do the work,
>>and probably we shouldn't even start to do it now, instead spending
>>all the resources to get mp2 out first.
>
>
> +1 for putting this on the back burner. Very soon there
> will be two apr versions in the wild: 0.9.X and 1.0.X. I
> think we should watch what sort of conflicts occur before
> ripping APR:: out of mp2.
>
> For instance, if APR:: were a separate release right now,
> post apr-1 some user will install the APR:: package from
> CPAN, and then later on might want httpd-2.0.50 with modperl2.
> After installing httpd-2.0.50, mp2 will then need to either
> tell this guy to replace httpd-2.0 with httpd-2.2, or reinstall
> a new APR:: using apr-0 instead (which may break other APR::
> apps he's already using), or else mp2 will have to supply its
> own APR:: modules, in a non-colliding fashion (probably via
> MP_INST_APACHE2=1, even though mp1 isn't even being discussed).
Good thinking, Joe. We may start to always install mp2 into Apache2/ then,
including its APR libs, so that it's self-contained.
There are going to be various tricky bugs to figure out with the new things. I
just had one when I tried:
perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; open my $fh, "<:APR",
"/tmp/xxx", APR::Pool->new; print <$fh>'
APR::PerlIO::read: (9) Bad file descriptor at -e line ...
it took me time to figure out that the pool has gone out of scope and was
destroyed by the time read was attempted. This fixed the problem:
perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le '; my $p = APR::Pool->new; open
my $fh, "<:APR", "/tmp/xxx", $p; print <$fh>'
tricky. We may need to have much more defending code if we don't want to get a
rain of bug reports. And writing it is not trivial at all :(
so in the case of open() we probably need to increment the refcount of the
pool object and decrement it on close and hope that we don't get a leak anywhere.
--
__________________________________________________________________
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: [apr] dropping Apache2/ subdir for APR::*
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Of course for this to happen we need more hands to do the work,
> and probably we shouldn't even start to do it now, instead spending
> all the resources to get mp2 out first.
+1 for putting this on the back burner. Very soon there
will be two apr versions in the wild: 0.9.X and 1.0.X. I
think we should watch what sort of conflicts occur before
ripping APR:: out of mp2.
For instance, if APR:: were a separate release right now,
post apr-1 some user will install the APR:: package from
CPAN, and then later on might want httpd-2.0.50 with modperl2.
After installing httpd-2.0.50, mp2 will then need to either
tell this guy to replace httpd-2.0 with httpd-2.2, or reinstall
a new APR:: using apr-0 instead (which may break other APR::
apps he's already using), or else mp2 will have to supply its
own APR:: modules, in a non-colliding fashion (probably via
MP_INST_APACHE2=1, even though mp1 isn't even being discussed).
Far more trouble that it's worth, IMHO.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org