Re: speeding up CGI.pm
On Tue, 25 Mar 2003, Stas Bekman wrote: [...] http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=2 If something can be made faster with very little effort, why not doing that? Often because the cost of having to deal with the increased complexity and new obscure bugs isn't worth it. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: speeding up CGI.pm
That would be really amazing if it could still be implemented in mp1, too, as it would allow for interoperability between libapreq-based applications (like Apache::UploadMeter) and response handlers like CGI scripts which use CGI.pm I suppose that this isn't such a big problem in mp2 whose filters will probably make using one API for request handling unnecessary... Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:41 AM Subject: speeding up CGI.pm While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ 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: speeding up CGI.pm
I like the idea of that, although the handsprings needed to do ordinary CGI, mp1 and mp2 might lead to a cloud of confusion. Best to keep them in separate modules and load them into CGI as needed. Is Apache::Request in mp2 ready for prime time? We haven't been able to get it running here (some sort of install problem, my people tell me). Lincoln On Tuesday 25 March 2003 03:25 am, Issac Goldstand wrote: That would be really amazing if it could still be implemented in mp1, too, as it would allow for interoperability between libapreq-based applications (like Apache::UploadMeter) and response handlers like CGI scripts which use CGI.pm I suppose that this isn't such a big problem in mp2 whose filters will probably make using one API for request handling unnecessary... Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:41 AM Subject: speeding up CGI.pm While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ 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: speeding up CGI.pm
On Tue, 25 Mar 2003, Lincoln Stein wrote:
I like the idea of that, although the handsprings needed to do ordinary CGI,
mp1 and mp2 might lead to a cloud of confusion. Best to keep them in
separate modules and load them into CGI as needed.
Is Apache::Request in mp2 ready for prime time? We haven't been able to get
it running here (some sort of install problem, my people tell me).
Not at all ready. I do not believe even a beta release has been made.
- nick
--
Nick Tonkin {|8^)
speeding up CGI.pm
While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ 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: speeding up CGI.pm
Stas Bekman wrote: While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? From an outsider's perspective, I agree. For some previous discussion (April 16, 2000) http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=2
Re: speeding up CGI.pm
Gunther Birznieks wrote: Stas Bekman wrote: While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? From an outsider's perspective, I agree. For some previous discussion (April 16, 2000) http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=2 If something can be made faster with very little effort, why not doing that? Certainly the degree of performance improvement depends on how heavy the request parsing is, but you get a better speed overall. __ 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
