This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: RFC: mod_perl advocacy project resurrection From: Gunther Birznieks <gunther@extropia.com> Date: Wed, 06 Dec 2000 07:33:45 +0800 I think the issue is Perl for web applications advocacy rather than mod_perl advocacy. If more people thought using Perl for web apps was cooler and easier than using PHP, then they would use Perl and then graduate to mod_perl when they were ready. As it is, PHP has 1-up on CGI/Perl. PHP is FAST while still having an easy programming model. Having an easy programming model was Perl's claim to fame and why web apps fluorished in CGI/Perl. But PHP added one thing -- speed -- and they are taking it all away from Perl. The problem is mod_perl is not easy. Make a CGI/Perl solution for speeding up CGIs EASY and you will find people migrating back from PHP to Perl. Attending the PHP talks at ApacheCon/Europe, if there was one thing I found, PHP as a language is still REALLY new. PHP4 is the first really professional version of PHP, PHP3 is filled with a lot of skeletons. And I heard people still arguing about PHP4's language merits. Rasmus posted on BUGTRAQ the other day about some security problems with PHP scripts coming up (there have been several in the last week)... He posted that anyone running the scripts should upgrade to PHP4. Yet people are still finding it hard to upgrade to PHP4. So those people will have to go through hoops to shutdown security problems in their public domain PHP apps? Larry Wall was a genius in creating a great language with ease of expression. But we didn't carry the torch to make it fast and easy. By the way, I *LOVE* SpeedyCGI and mod_speedy. I forget who mentioned it to me at ApacheCon/Europe, but THANK YOU SO MUCH. For those of you that have not seen the project, please try it out. It makes speeding up CGI/Perl almost trivial. And it's definitely an ISPable solution because it plugs into Apache's CGI mechanism (non of the annoyance of giving plain users control over handlers). And oh yeah, SpeedyCGI is web server independent. It works just as well on Netscape (which is where I had to use it on a client site). The model is similar to FastCGI, but SpeedyCGI is trivial to setup unlike FastCGI which requires modification to the app. ===