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 Mon, 22 Nov 2004 00:03:10 GMT
Stas Bekman <stas@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 <radek@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

Mime
View raw message