On Fri, 12 May 2000, Doug MacEachern wrote:
> On Sat, 6 May 2000, Gunther Birznieks wrote:
>
> > At 06:56 PM 5/5/00 -0400, Jim Winstead wrote:
> > >On May 05, Adi wrote:
> > > > You can still use CGI.pm from within mod_perl (and you should). There is
> > > > nothing better at handling data passed from a browser via HTTP POST and/or
> > > > GET. If you currently use CGI.pm, I think you'll find that a lot of your
> > > > current code can simply be cut-and-pasted into a mod_perl setup.
> > >
> > >Well, arguably Apache::Request is better at handling data passed
> > >from a browser via HTTP POST and/or GET in a mod_perl environment.
> > >And it has the advantage that is entirely focused on request
> > >handling, and doesn't have any of the HTML generation cruft like
> > >CGI.pm.
> >
> > The "HTML Generation cruft" is optional "cruft" and doesn't have to be
> > compiled in.
>
> not compiled, but the all the code lives in a BIG hash table for CGI.pm to
> autoload from. the export lists take up alot of space too. regardless if
> you're using html routines or not.
As I have replied to FEITO Nazareno today, this happens only if you
precompile CGI.pm's functions at the server startup. I've used B::Terse in
/perl-status to check that. Refer to the post with subject "[iso-8859-1]
Whats better?program with C...." for a complete showcase.
If you don't precompile them, only the minumum set of functions will be
inherited, so it's possible to exclude the html generation functions.
______________________________________________________________________
Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.org http://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
----------------------------------------------------------------------
