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.
  • Thanks for sharing this idea. Do you also extend it to Apache/mod_perl usage? I would like to upgrade Perl from 5.8 to 5.10 in a project that is deployed on a development machine and four mod_perl production web servers. If I expect the current code can run under 5.8 and 5.10 with no modifications, perhaps it doesn't have to be so complicated.
    • Hmm, that’s a good question. I don’t know, nor am I likely to figure anything out. My own tendency has been to treat mod_perl as something to use specifically for writing Apache modules, but to not use Apache modules as a web app deployment platform.

      For that I now prefer an in-process HTTP implementation – in this case, Catalyst::Engine::HTTP::Prefork – along with whatever reverse proxy is most handy. I also don’t bother with highly involved configurations for serving static files, I just use Catalyst::Plugin::Static::Simple (which you’re not supposed to do, according to orthodoxy) and let the reverse proxy take care of serving those files without backend server load. The overall result is a drastic simplification of the deployment process, accompanied by a significant increase in flexibility, with the added bonus that the development system setup differs from the production box only in the absence of a reverse proxy. (And it’s not different to remove that difference – you can set up a reverse proxy on a dev box quite easily if you need to, and you can also probe the app server on the production box without going through the reverse proxy.) Process model wise this setup is very similar to the typical configuration of a slim Apache that serves static files and reverse proxies to a mod_perl-enabled Apache that runs the app, just a lot less heavyweight.

      So I have lost almost all of my interest in mod_perl.

      • Thanks for sharing your techniques. How do you handle some of the functions typically be handled by Apache in web application, for example, rewrites, redirects and aliases (allowing a directory outside the web server root to appear within it)?
        • All decent dedicated reverse proxies have features on par with mod_rewrite, so it’s not hard to adapt the practice accordingly. However, rather than using such features for everything I have actually come to consider some of that work, esp. redirects, as part of the app itself – f.ex. redirects to support the URI structure of an old version of the app. So I write logic for them in the app using the framework’s features. The reverse proxy is the place for rewrites that concern the integrati