[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl-dev
Subject:    Re: [apr] dropping Apache2/ subdir for APR::*
From:       Stas Bekman <stas () stason ! org>
Date:       2004-11-22 2:46:09
Message-ID: 41A152F1.2090900 () stason ! org
[Download RAW message or body]

Radoslaw Zielinski wrote:
> 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.

That's the problem. I still can't quite understand how exactly you are 
going to solve the problem I'm talking about. The devil is in the detail.

>>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.

That's what I understand (assumed) that you have suggested. If not then 
please explain again, since I don't understand how else mp2 will know 
which of the two APIs it needs to invoke.

>>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).

that will mean that it's not possible to mix mp1 and mp2 code. e.g. if you 
have some module that works under mp2 only?

> 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.

You mean you rebless it and call the same method again, thus 
Apache2::Connection::local_addr is never touched? So it is all governed by 
what class the object is blessed into? Man, that's a big big mess. Granted 
it might work if one figures out how to juggle the $c (and other) objects. 
Still if you ever get a situation that both APIs happen to run under the 
same <Location> you are in a big trouble.

-- 
__________________________________________________________________
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

[prev in list] [next in list] [prev in thread] [next in thread]