perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radoslaw Zielinski <>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Sun, 21 Nov 2004 18:58:13 GMT
Stas Bekman <> [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/' => [
      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);

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 <>
[ GPG key: ]

View raw message