Stas Bekman <[EMAIL PROTECTED]> [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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
