In many casee, the hard part to deploy mod_perl application seem due to the huge memory usage. But this can be solved by using the dual (light+modperl) setup. The dual setup has also another advantage: it allows virtual hosting users to run his own standalone Apache at a given port (have the light server to proxy to that port.) The virtual host user still needs to restart his mod_perl if program changes, but the light server does not, and so the other users won't be affected.
The example you mentioned about using Java over Perl looks interesting. Can you be more specific, since we rarely hear cases where Perl can't do but Java. :-) siberian wrote: Tue, 30 Nov 2004 15:00:45 -0800 <don flamesuit> One thing people don't talk about much is deployability. I've had to start moving away from ModPerl in some situations for just this reason. For example, my recent projects revolve around a public server that everyone can use with the option to install a local server on their network that delivers the same functionality (same codebase with some some tweaks based on its configuration status). The install has to go smoothly every single time on a variety of platforms. Originally I tried to get modperl up in this environment and it really just was tough., module dependancies, things like that. Additionally, and I know this is not cool to say, I didn't really want the entire codebase sitting on someone's machine since its a shrinkwrap product in a highly competitive space. Yea yea, you can reverse compile java classes etc etc etc, its just not the same as 'open the .pm file'. So that lead to java (Tomcat+Struts) which pretty quickly and easily gave me a single package deployment method, no source included and with no dependancies to speak of. Its literally a double-click installer and a reboot(just to be cautious, not really required) and the entire system is up and running with a reverse proxy, tomcat, struts and all our apps. I know I could have accomplished this with modperl but having done many modperl install packages in the past I know its just not as easy and not nearly as bulletproof. I still use a lot of modperl (South African Airways Holidays etc) but whenever deployability is a key feature I've moved to Java. Its not so bad once you get used to doing things in longhand ;) Solve the deployability issue and I'd jump back in a heartbeat on those projects. A better way to package dependancies up, obsfuscated source etc. </remove flamesuit> John, still loving my modperl but I've gone to the dark side on more regular basis over the last year. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
