Stas Bekman <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]>
[ GPG key: http://radek.karnet.pl/ ]
pgpm1MJyoPa4u.pgp
Description: PGP signature
