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.
- Original Message Follows -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Why people not using mod_perl
Date: Tue, 30 Nov 2004 22:38:11 +
Hi, there:
just subscribed to this advocacy list.
First, sorry to Frank. I was replying his email in the
user list but was wrongly put his address as the subject.
:-(
Please let me share some of my experiences in using
mod_perl.
There are four factors when choose a particular language:
1) easy to program
cgi is very easy to use, and php is easy. mod_perl and
java servlet are hard.
2) speed
mod_perl is fast but php is fast too (if not faster),
and so is Java servlet.
3) capacity/scalable
mod_perl is very scalable --- I mean, one can properly
config a single server to handle dynamic content for
200K daily unique IPs. PHP may end up with just 100K
and servlet ends up at around 50K.
However, even the old CGI can handle 20K unique IPs
with a new CPU. Since most sites won't
need to go above 20K IPs, this advantage is not that
attractive in practice.
And what is worse is that the current existing mod_perl
toolkits seem not scalable when compared to PHP. I knew
2 cases where people gave up the mod_perl toolkit
and turned to PHP.
4) easy to manage, work as team
both mod_perl and servlet are good to be written in OO
(and the so-called MVC). PHP is bad.
But again, majority webmasters don't need OO or MVC.
5) learning curve, friendly environment, existing
applications etc.
PHP is the best, then serverlet; mod_perl is the worst.
Based on the above situation, we see that the potential
mod_perl users are those who are using or will choose
Java servlet, and advanced PHP users who need the
projects to be in OO and MVC.
To advocate mod_perl, the priorities rank as:
1) focus on mod_perl's ability of OO / MVC
2) scalability (only the original mod_perl, not toolkits)
3) and speed
4) avoid toolkits but diretly go to XHTML.
POD MERL
--
--- To unsubscribe, e-mail:
[EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
