While we're talking about mod_perl, perhaps I can throw out a few reasons why I have chosen it over other languages and technologies. This might help us figure out where we need to do some intial PR work.
We currently have our account management code using PHP (this is for about 100k accounts). We made this choice because that is what our vendor supported with their libraries. Unfortunately, the libraries had run-time assertions in them that made them unusable in a production environment, but we didn't find this out until we had gone production. The alternative at the time was Tcl if we wanted to use vendor supported platforms. I was very aware of mod_perl at the time, but was unable to use it because of the vendor support. Now that we know we can't use what the vendor supplied, we are free to use a different platform, and we are moving in that direction. The reasons I do not want to maintain our application in PHP (< 5): o No Namespaces o Poor object implementation - defaults to pass by copy instead of by reference (unexpected) o Difficult to separate along MVC lines (thus customer service won't touch anything for fear of messing up a program) o Difficult to manage exceptions o Configurations are parsed on each and every request o PHP is based on building small web sites o No support for testing o No support for documentation o No standard way to package and distribute an application o No way to declare variables / manage typos Some of these might be due to my inexperience with the language (I learned it by writing the account management system) and my expectations from Perl. The reasons I am going with mod_perl: o All the benefits of Perl + namespaces + objects passed by reference by default (due to how they are constructed) + unit testing + pod + CPAN + distribution / packaging standard + use strict + map, grep, and other lispy constructs + dangling commas are allowed o Perl has a strong sys admin history o Server startup hooks, so configurations can be parsed at startup and cached - allows more requests / sec. o Better integration with Apache request management, so I can control each of the different phases as much as I need to -- Apache is an integral part of my application instead of something feeding requests to my code I am not being exhaustive, but I think it gives some idea of what I find important in my development environment. The conclusion seems to be that PHP is nice for small systems and applications, but for larger, more complex projects, mod_perl is the only one of the two that can compete with the expectations coming from the Java side (which, as much as we may hate being compared to Java, we have to address if we are going to make headway in shops that are already using Java). Perhaps we can find ways to leverage that. -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html