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.
At 09:22 AM 12/5/00 -0800, Paul wrote:
>--- Stas Bekman <[EMAIL PROTECTED]> wrote:
>.....
> > I see two main streams:
> > 1) Online zines.
> > 2) Conferences.
>
>Apache.org has a whole subsection devoted to mod_perl....
>Any idea what it would take to get a link there from webs like tpj and
>Perl.com? I was thinking that perl.com has a nice series of articles
>going for newcomers to the language, and Mark Jason-Dominus' series of
>red-flag articles has certainly been worth a read; wouldn't a less
>generic article series for less-new users interested in perl topics
>like Apache be worth space and a link? I've seen links to specific
>high-profile uses like the Human Genome Project as Perl advocacy.
>Wouldn't mod_perl be worth an ongoing link page in that right, perhaps
>with discussions of sites handling thorny problems? Or am I behind the
>times on that one?
>
>I'd even volunteer to write a few articles, though I hardly consider
>myself qualified to teach anything more than the basic concepts. I'm
>still on the steep side of the learning curve for designing effective
>and efficient subsites with handlers and some Embperl, but our shop has
>some odd needs that mod_perl seems built-for, and I do love to talk....
>
>comments?
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Shopping - Thousands of Stores. Millions of Products.
>http://shopping.yahoo.com/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
