I can do this (changing the new() call to accept $r). My understanding is that client code will need to be changed to take advantage of this, right?
That's correct. $r should be explicitly passed. However the CGI-side code doesn't have to specific to mod_perl 2.0. CGI should be able to do that with either version of mod_perl. In this case the user code can be ported to work with both versions of mod_perl.
How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it.
The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use.
You can still have an accessor function to set $r:
use CGI; CGI->r($r);
I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this?
Not, under threaded mpm. Since the code should work the same with threaded and non-threaded mpm, it's a problem for any 2.0 code. The problem with Apache->request is that it involves storing and retrieving data from the TLS (thread local storage), which is slow. So while the functionality is there, sites that are looking for high performance will want to pass $r, rather than rely on Apache->request.
Of course one can argue, that sites looking for high performance should use Apache::Request (which is not quite there yet, for 2.0). So if this argument is valid and you don't feel like changing the API, that's cool too. May be in the future.
__________________________________________________________________ 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
