perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Sun, 21 Nov 2004 17:39:00 GMT
Radoslaw Zielinski wrote:
> 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.

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


Mime
View raw message