On Tue, Jun 05, 2012 at 08:37:33AM -0400, Mark Haney wrote: > On 06/04/2012 09:25 PM, pangj wrote: > > > >>I want to understand why Mark thinks he needs mod_perl. If it's just > >>because he wants to speed up his app (soup up the engine) there might > >>be things he can do that don't require rewriting a lot of code, or > >>spending a lot of time learning a lot of new ways of doing things. > > > >Me second. > >If the OP just wants to speed up his app based on perl CGI, then modperl > >registry is a good suite. > > > > > > Honestly, it's really not even that complicated. I've been hearing > that using CGI.pm is 'outdated', 'uncool', whatever you want to call > it. And generally speaking the statement after that is about > mod_perl. > > My entire reason behind asking about mod_perl is really just to use > methodologies/best practices/models that are in use now, rather than > something out of real use a decade past. It's really more keeping > the code up to date for the future than any other reason. > > Does that make sense? Yes it does :)
It seems CGI.pm still has it's defenders so I wouldn't completely knock it out of the woods. You're okay with mod_perl if you have control of your Apache configuration and it provides huge speed advantages. (I am currently unable to provide a reference URL on that but I was amazed by the speed (slow) and resource usage (large) of CGI.pm. I can't recall whether it was posted here or on another list but if I can trace it I'll provide it. However it has left me with the idea of not using CGI.pm again and shifting to mod_perl or Plack/PSGI.) My preferred starting point on mod_perl is http://perl.apache.org/ and then try googling or asking on this list. The Plack/PSGI approach uses the Plack interface - see http://www.perlnights.com/?action=show_thread&threadid=140 for an explanation of Plack/PSGI and there's more Plack/PSGIness at http://www.perlnights.com/?action=show_section§ionid=3 . I can't recall if Plack/PSGI was on the aforementioned lost URL. http://jjnapiorkowski.typepad.com/modern-perl/2011/08/catalyst-59-less-code-more-plack.html talks about Catalyst and Plack, raising, for me at least, consideration of the seperation of concerns - in this case web server configuration versus web application. The Debian package libplack-perl states : Description: interface between web servers and Perl web applications Plack is a set of tools similar to Ruby's Rack or Python's Paste for WSGI. It implements the Perl Server Gateway Interface (PSGI) standard interface, which allows developers to decouple their web application framework from the local web server environment. And there's the originator's site http://advent.plackperl.org/ to start with. Whoever advised you that CGI.pm was dead and that you should look to mod_perl may in fact favour mod_perl over Plack/PSGI, may be better placed to offer further advice on mod_perl or may be a little outmoded in their advice. CGI.pm is not dead, just slow and greedy. Mod_perl is speedy, lean and perhaps could be considered stable and controllable - for some values of stability and control. Plack/PSGI is new and fast but both Catalyst and Plack have dependencies which might be a problem if one of the dependencies were to break. As with all things Perl, it's up to you what you want to use/learn. Hope all this helps. Kind Regards Lesley -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
