perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [apr] dropping Apache2/ subdir for APR::*
Date Sun, 21 Nov 2004 19:37:51 GMT
Radoslaw Zielinski wrote:
> Stas Bekman <stas@stason.org> [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));
>       },
>       ...,
>     }
>   ],

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

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?

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

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

Please see my question above.

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

Understood.


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


Mime
View raw message