NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
What’s the point? (Score:1)
What’s the use of HTTP::Engine when you’re running under CGI anyway? Might as well cut out the middle men and just use CGI::Simple. At least then you have no worries about latency.
It doesn’t provide a sensible upgrade path anyway, since engineering for minimal startup time is so different from engineering for a persistent environment. You don’t want to just take a CGI script verbatim and run it as a server, even if that script happens to be written against HTTP::Engine.
Re:What’s the point? (Score:1)
I think a "use case" might be something like Movable Type. When they distribute it, they don't know ahead of time whether it will be deployed in CGI, FastCGI, or mod_perl, so they code it work in all three, and could HTTP::Engine to abstract which backend is in use.
I actually use Movable Type in CGI because it was easy to deploy that way, and nearly all the public parts are rendered as static HTML. The admin interface is a bit slow, but I'm not the only user and it's fast enough for me.
Currently the Movable Type has "$ENV{MOD_PERL}" conditional logic throughout the code base... it's rather messy. Switching to HTTP::Engine (or similar) would be a big improvement for that kind of project.
I would agree that if you only ever plan to deploy in CGI, than an extra backend abstraction layer is just extra waste and complexity.
Reply to This
Parent