Re: [WISH] A Perlish way to detect mod_perl major version (= not $ENV{MOD_PERL})
[prev]
[thread]
[next]
[Date index for 2005/03/18]
-----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-----