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