Re: the deprecation of Apache-request in mp2
Hello, NTI sure hope not! I second John Siracusa's post on this. Keep the HTML NTgeneration well away from request parsing, please! I personally am 100% in the camp of keeping HTML generation separate from quest parsing, but I do recognize the advantage of having API level compatibility between Apache::Request and CGI, so that you could switch from one to another easily. I think this would be a big win for mod_perl overall from the port your scripts quickly point of view. I think a good compromise would be to keep the HTML generation code in an entirely separate module, like Apache::Request::HTML or something. That class could augment Apache::Request with new methods. (This is somewhat similar to how Apache::File and Apache::Log augment the Apache class with new methods.) This seems to satisfy both sides, and accomplish the laudable goal of making CGI and Apache::Request API compatible without bloating up the normal use of Apache::Request. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: the deprecation of Apache-request in mp2
On Tue, 25 Mar 2003, Stas Bekman wrote:
Lincoln Stein wrote:
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.
Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around two instances: $r and $q.
- assuming that CGI.pm-specific code is not used one can transparently switch
between Apache::Request and CGI.pm, by just changing:
$r = Apache::Request-new($r);
$r = CGI-new($r);
And of course Apache::Request is a subclass of Apache ($r) and it works pretty
well.
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
I sure hope not! I second John Siracusa's post on this. Keep the HTML generation well
away from request parsing, please!
- nick
--
Nick Tonkin {|8^)
Re: the deprecation of Apache-request in mp2
I suppose there might be name clashes, but I'll look into doing that. Lincoln On Monday 24 March 2003 07:08 pm, Stas Bekman wrote: Lincoln Stein wrote: 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. Sounds interesting. What would be the advantage of that? The advantage is that - you don't have to keep around two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request-new($r); $r = CGI-new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. __ Stas BekmanJAm_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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache-request in mp2
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? The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Lincoln On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote: One more issue with CGI.pm and mp2, and other modules as well. CGI.pm is using Apache-request. The setting/retrieval of the global request record under threads is expensive, so the use of Apache-request is deprecated in mp2. If CGI.pm can be changed to optionally accept $r (as an argument to new(), plus a special accessor to set later) and use it instead, this will improve the performance if Apache-request is not set. Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by default with 'SetHandler perl-script') that is half of the performance hit (store), and the actual use of Apache-request (get) is the second half. See: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ __ Stas BekmanJAm_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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache-request in mp2
Lincoln Stein wrote: 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 BekmanJAm_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
Re: the deprecation of Apache-request in mp2
Lincoln Stein wrote: 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. Sounds interesting. What would be the advantage of that? The advantage is that - you don't have to keep around two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request-new($r); $r = CGI-new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. __ Stas BekmanJAm_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
Re: the deprecation of Apache-request in mp2
On 3/24/03 7:08 PM, Stas Bekman wrote: In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. I've always thought that HTML generation does not belong in CGI.pm, so I don't see duplicating that functionality in an extended $r as a useful goal. Better to separate the HTML stuff (preferably into HTML widget objects, IMO) from request parsing and response formulation and delivery. -John
the deprecation of Apache-request in mp2
One more issue with CGI.pm and mp2, and other modules as well. CGI.pm is using Apache-request. The setting/retrieval of the global request record under threads is expensive, so the use of Apache-request is deprecated in mp2. If CGI.pm can be changed to optionally accept $r (as an argument to new(), plus a special accessor to set later) and use it instead, this will improve the performance if Apache-request is not set. Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by default with 'SetHandler perl-script') that is half of the performance hit (store), and the actual use of Apache-request (get) is the second half. See: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_request_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ __ Stas BekmanJAm_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
