Many messages on this list perpetuate the notion that usage of CGI.pm and
Apache::Registry is for beginners. Popular opinion is that you're not a
leet mod_perl h@x0r until you wean yourself from CGI.pm and Apache::Registry
and "graduate" to the Apache API. With this in mind, there have been many
messages over the years making blanket statements along the lines of "CGI.pm
is evil" and/or "Apache::Registry sux". I'm trying to identify the source
of this disatisfaction. While it may seem that my intent is to start the
ultimate, end-all CGI.pm/Apache::Registry flame war, please be assured that
I am interested in ferreting out the real issues. :-)
Anyway, in hope of generating some debate, I'll make some (potentially
inflammatory) assertions:
1. An Apache handler doesn't mean CGI.pm *ISN'T* in use
The "Apache::Registry sux" crowd claims I should forgo Apache::Registry and
write handlers instead. Okay, here's my handler:
# in httpd.conf
<Location /foo>
SetHandler perl-script
PerlHandler Apache::Foo
</Location>
package Apache::Foo;
use strict;
use CGI ();
sub handler {
my $q = CGI->new;
print $q->header;
print "Hello World\n";
200;
}
1;
Satisfied? No Apache::Registry in use here. Am I a l33t h@x0r now? No?
Why not? Oh, so when the zealots say, "Apache::Registry sux, write handlers
instead" they really mean I should be using the Apache API instead of
CGI.pm. I see.
I have another beef with the "CGI emulation sux, avoid Apache::Registry"
crowd. And that is:
2. Just because you don't use Apache::Registry doesn't mean you're not doing
CGI emulation (*gasp*)
What exactly is this "evil, bloated, slow CGI emulation" that everyone's
trying to avoid? Is it the overheard of setting up all the environment
variables? Well, gee whiz, regular handlers do this too unless you tell
them not to. Try the following exercise:
<Location /env>
#PerlSetupEnv Off # try first without; then try with PerlSetupEnv Off
SetHandler perl-script
PerlHandler Apache::Env
</Location>
package Apache::Env;
use strict;
use Data::Dumper qw(Dumper);
sub handler {
my $r = shift;
$r->content_type('text/plain');
$r->send_http_header;
$r->print(Dumper(\%ENV));
200;
}
1;
So let's not be so quick to curse Apache::Registry for it's "slow" CGI
emulation. Your "fast" handlers are probably doing the same thing
unbeknownst to you.
Another assertion:
3. Using Apache::Registry doesn't necessarily mean CGI.pm is at use
It seems the "Apache::Registry sux" crowd dislikes Apache::Registry because
it implies that CGI.pm is in use. Perhaps their real gripe is one should
use the Apache API instead of CGI.pm's methods. So how would they feel
about this:
# in httpd.conf
<Location /bar>
PerlSetupEnv Off # we don't need no stinking ENV
SetHandler perl-script
PerlHandler Apache::Registry # or Apache::RegistryNG->handler
Options +ExecCGI
</Location>
#!/usr/local/bin/perl -w
use strict;
my $r = Apache->request;
$r->content_type("text/html");
$r->send_http_header;
$r->print("Hi There!");
Does this count? Am I a l33t h@x0r because I used the Apache API? Or am I
still a lamer for using Apache::Registry?
I can hear the hordes out there crying, "Why use Apache::Registry if you're
not using CGI.pm?" Well, perhaps I have a couple hundred scripts and don't
want to maintain several hundred <Location> directives in httpd.conf. Maybe
I like Apache::Registry's convenient way of grabbing my script, wrapping it
into a handler on-the-fly, and serving it up. Isn't this one of the handier
features of Apache::Registry? (Note: I'd like to hear of alternatives to
Apache::Registry[BB|NG] for doing this.)
So maybe Apache::Registry isn't pure evil after all. So perhaps the zealots
clarify their mantra to be simply "CGI.pm sux". That leads us to the next
assertion.
4. Using CGI.pm is smart (aka don't reinvent CGI.pm's HTML methods)
Somewhere along the line, CGI.pm became "bad, evil, and bloated". Many of
you don't want to use CGI.pm for anything. While some of CGI.pm's
functionality can be done more efficiently by other means (i.e.
Apache::Request), CGI.pm's HTML methods have no such high-efficiency
equivalents. Since laziness is one of the primary Perl virtues, isn't it
smart to leverage the work already done in CGI.pm rather than rolling your
own HTML methods? Can't using CGI.pm's HTML methods be considered a "good
thing"?
The recent thread "[ot] How to crypt the way htpasswd does..." serves as an
example of how one can get chastised for failure to use existing code. (See
http://forum.swarthmore.edu/epigone/modperl/nengahker for the thread.) Why
are so many of you quick to ignore this advice? Why is this particular
wheel one so many of you are willing to reinvent? Would the anti-CGI.pm
crowd be more likely to use these HTML functions if they were in their own
(presumably leaner) module unbundled from the "bloated, monolithic" CGI.pm?
With all this in mind, we can finally arrive at...
5. Don't use CGI.pm for what can be done elsewhere, faster
Perhaps this is what most of you performance mongers really mean. Don't use
CGI.pm to do stuff the API can do -- use the Apache API or Apache::Request
instead. And be sure to set "PerlSetupEnv Off" unless you need it. This
seems like good advice. See how easy it is to give out good advice without
any disparaging comments against CGI.pm or Apache::Registry. :-)
So I'm hoping you'll agree that it's still possible to have a
highly-efficient system and be a leet mod_perl h@x0r while still using
CGI.pm and Apache::Registry. Leveraging CGI.pm's HTML functions is smarter
than reinventing your own. And the use of Apache::Registry doesn't
necessarily mean CGI.pm or "CGI emulation" are in use.
Thanks in advance for your flames, er... replies.
Matt
P.S. The terms l33t h@x0r, zealot, performance monger, and code wanker are
intended to be complimentary -- not inflammatory. (Well, okay, code wanker
is intended to be inflammatory, but I never used that term.)
P.P.S. I should have some benchmarks soon showing CGI.pm vs.
Apache::Request, handler vs. Apache::Registry vs. Apache::RegistryBB,
PerlSetupEnv Off vs. On, etc.
