mod_perl v. mod

stuckey has asked for the wisdom of the Perl Monks concerning the following question:

A very general question for the monks: For the last five years my group has maintained a web services application based in mod_perl. When we built the app, mod_perl 2 and Apache 2 were still cutting teeth, and over the intervening years, we regrettably lost track of advancements.

Now we're looking to build a new app more or less from the ground up. It's to be a fairly straightforward content management system (though specialized enough to rule out available Open Source CMS systems), with session mgmt, user levels, simple workflow, etc.

So I'm interested in hearing opinions as to the pros and cons of moving to a mod_perl 2/Apache 2 environment. So far, web searches have provided surprisingly little guidance. I'd expected by now the newer versions to've become the de facto standard for mod_perl development -- and perhaps the have, but several recent articles suggest a lot of people are still working with older versions.

Is there any reason 'not' to move to Apache2/mod_perl2? Any compelling reasons 'to' make the change?

Any advice or pointers to articles would be very much appreciated.

Thanks,
RS

Comment on mod_perl v. mod_perl 2

Replies are listed 'Best First'.
Re: mod_perl v. mod_perl 2 by Anonymous Monk on Feb 21, 2008 at 05:56 UTC
http://modperl2book.org/ As with any major upgrade, there are new features and key changes to mod_perl from the 1.x generation. The mod_perl 2 User's Guide explains these key changes and demonstrates the tools that you can use to port modules and migrate your existing code. Improvements in Apache 2 and mod_perl 2 include: Multi-Processing Model modules (MPMs) allow for process-based and thread-based processing models. The addition of thread support makes mod_perl viable on Win32 and introduces the potential for improved performance on other platforms. Protocol Modules give Apache and mod_perl the potential to serve any protocol, not just HTTP. A mod_perl 2 interface to the Apache filtering API gives full access to input and output filters from Perl. Support for creating custom Apache configuration directives in pure Perl, improved options for passing values to Perl modules from Apache, and greater access to the Apache configuration values. The `Apache::Test` testing framework, useful for Perl and non-Perl Apache modules, allows you to develop fully-tested web applications to verify features and guard against regression. The ability to easily subclass `ModPerl::Registry` and override methods as needed. http://perlbuzz.com/2007/09/interview-with-jim-brandt-coauthor-of-mod-perl-2-u.html Andy: You say that mod_perl 2 is the future, but what if I've got a perfectly good, working stable app running under Apache 1 and mod_perl 1. Staying on mod_perl 1 is certainly building up technical debt, but what does mod_perl 2 give me for my troubles? ...	[reply] [d/l] [select]
Re: mod_perl v. mod_perl 2 by CountZero (Bishop) on Feb 21, 2008 at 06:46 UTC
If your server runs on a Windows system and you really want to get the benefit from the speed-up mod-perl provides, you have to make the switch. Also the API is much more straightforward and you have access to every little nook and crannie of the Apache-server. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]