perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radoslaw Zielinski <ra...@karnet.pl>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Sun, 21 Nov 2004 17:29:17 GMT
Stas Bekman <stas@stason.org> [21-11-2004 17:48]:
> Radoslaw Zielinski wrote:
>> Stas Bekman <stas@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 <radek@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

Mime
View raw message