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