i think anyone who is not writing their own custom kernel in direct machine code
to handle all requests directly from the NIC is a lamer. but that's just mee.
sorry for the extra e on the end of mee but 00000111 is too many switches to
throw
just to get a backspace. :-)
cliff rayman
genwax.com
Matt Arnold wrote:
> 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.
