Re: [WISH] A Perlish way to detect mod_perl major version (= not $ENV{MOD_PERL})

[prev] [thread] [next] [Date index for 2005/03/18]

From: Dominique Quatravaux
Subject: Re: [WISH] A Perlish way to detect mod_perl major version (= not $ENV{MOD_PERL})
Date: 11:07 on 18 Mar 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Geoffrey Young wrote:

| just added to svn is $ENV{MOD_PERL_API_VERSION}, which is currently
| just "2".
|
| I guess I understand why it's somewhat inconvenient sometimes to
| rely on %ENV, as with the system() example, but I'm not so sure
| that %ENV isn't sufficient

Well I admit it's mostly an elegance issue, but IMHO as important as
elegance issues get. Thinking in programming terms, "declaring" the
API version in %ENV is not the proper "scope" as environment variables
span processes and can be read / altered by just about anything (Perl
code or not). By contrast, the availability of the Apache machinery
through mod_perl is a per-process, Perl-only property and therefore
the logic that detects this situation should be implemented under a
scope with similar properties (e.g. sub mod_perl::API_VERSION()).

Using %ENV to carry perl-specific information around very much looks
like a thinko from the CGI mindset to me (compare "PerlSetupEnv"):
$ENV{MOD_PERL} simply imitates e.g. $ENV{GATEWAY_INTERFACE} - using
the POSIX env for the latter being the correct "scope" indeed, because
the Apache <-> CGI API occurs over POSIX pipework and Perl may not be
involved at all.

| what exactly is the issue you guys are trying to work around?

Practically, not much: as outlined elsewhere in the thread, we can
stumble along with what we have, it's just not very elegant - in my
case, I mostly have to examine $ENV{MOD_PERL} before erasing it and
store the result in a global variable. The system() issue was just a
thought experiment intended to get your attention :-) (and I'm glad to
learn that CGI.pm does The Right Thing).

Perhaps there is a "political" motivation, if we must have one: the
%ENV confusion may be one of the reasons why mod_perl 1 got
misunderstood as just CGI on steroids. (Well at least _I_ got all
confused from that once upon a time when reading CGI.pm's source.)

| - eval { Apache->server } or somesuch would clearly let you know
| whether or not you're running under mod_perl or a forked process.

This is what I used to do in MP1, but it doesn't work under mod_perl 2
if Apache::RequestRec is not loaded yet - ergo I can't decide whether
to "use Apache2;" in <Perl> on that basis. And I can't tentatively
"BEGIN { eval { require Apache2::RequestRec; }}" and catch exceptions
either, because I have a dual-version setup and loading random Apache2
modules under MP1 might just as well succeed, or even worse, succeed
*partially*.

If there were an "always-on" replacement to Apache->server directly
built into mod_perl.so itself, then everything would be lovely. And
while we are at it, we could call it "mod_perl::API_VERSION()" and
have it return a constant number (this would be quite cheap
resource-wise).

Well, I guess I should get off my rear and implement my proposal so
that everything becomes crystal clear :-)

- --
Dominique QUATRAVAUX                           Ingénieur senior
01 44 42 00 08                                 IDEALX

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCOrZuMJAKAU3mjcsRAogyAJwKc1CLgJk1+gIl+OsJsT5fxFnorQCfSy8I
0aMBmL9KvB2mEaew2oyrCHg=
=8boE
-----END PGP SIGNATURE-----


Re: [WISH] A Perlish way to detect mod_perl major version (= not $ENV{MOD_PERL})
Dominique Quatravaux 11:07 on 18 Mar 2005

Generated at 15:10 on 27 Mar 2005 by mariachi v0.52