Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

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