On Tue, 30 Nov 2004 22:38:11 +0000 [EMAIL PROTECTED] wrote: > First, sorry to Frank. I was replying his email in the user list > but was wrongly put his address as the subject. :-(
No worries. > 1) easy to program > > cgi is very easy to use, and php is easy. mod_perl and > java servlet are hard. A Perl CGI can easily be "mod_perl enhanced" by a few simple Apache configuration changes. I don't see what is so hard about that. I also think mod_perl is much easier for a Perl programmer to migrate toward than a Perl programmer taking up PHP or Java. The learning curve is bitten off in more easily digestable chunks. > 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. I'm not sure which toolkit they gave up on, but I've found that a lot of people give up too easily on these things. Often their problem can be solved by a few quick config changes and tweaks if they would just google for it or ask on a mailing list. Also, like you said most sites will never run into these problems and some of us aren't running traditional websites with mod_perl, but using it for web applications that aren't hit at the same rates as websites. > 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. I think this is more of a function of how the programmers work than the language or programming methodology. History has shown you can build large projects with hundreds of developers in a non-OO style and with no revision control ( read linux kernel until a few years ago ). > 5) learning curve, friendly environment, existing applications etc. > > PHP is the best, then serverlet; mod_perl is the worst. Learning curve really depends on where you are coming from. If you're talking about a webmaster that only knows Dreamweaver, XHTML, and a smattering of CSS, learning Java servelets and mod_perl are probably on equal footing. However, if you already know a smattering of Perl, which most webmasters or admins already do, then learning mod_perl is just another small step. You already know the language, you just have to learn the Apache API. > 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. I disagree with this a bit as the toolkits can scale, they just sometimes need to be tuned for a site. For example, I know there are large sites out that using Template Toolkit and Mason without any trouble. I'm sure they have had to tweak their configs, but if you're running a large scale website without doing some tweaking you are spending WAY too much money on hardware! :) --------------------------------- Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org --------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
