At 09:16 PM 12/21/00 +0100, Stas Bekman wrote:
[much removed]
>So the moment mod_perl 2.0 hits the shelves, this possible benefit
>of speedycgi over mod_perl becomes irrelevant. I think this more or less
>summarizes this thread.
I think you are right about the summarization. However, I also think it's
unfair for people here to pin too many hopes on mod_perl 2.0.
First Apache 2.0 has to be fully released. It's still in Alpha! Then,
mod_perl 2.0 has to be released. I haven't seen any realistic timelines
that indicate to me that these will be released and stable for production
use in only a few months time. And Apache 2.0 has been worked on for years.
I first saw a talk on Apache 2.0's architecture at the first ApacheCon 2
years ago! To be fair, back then they were using Mozilla's NPR which I
think they learned from, threw away, and rewrote from scratch after all (to
become APR). But still, the point is that it's been a long time and
probably will be a while yet.
Who in their right mind would pin their business or production database on
the hope that mod_perl 2.0 comes out in a few months? I don't think anyone
would. Sam has a solution that works now, and is open source and provides
some benefits for web applications that mod_perl and apache is not as
efficient at for some types of applications.
As people interested in Perl, we should be embracing these alternatives not
telling people to wait for new versions of software that may not come out soon.
If there is a problem with mod_perl advocacy, it's that it is precisely too
mod_perl centric. Mod_perl is a niche crowd which has a high learning
curve. I think the technology mod_perl offers is great, but as has been
said before, the problem is that people are going to PHP away from Perl. If
more people had easier solutions to implement their simple apps in Perl yet
be as fast as PHP, less people would go to PHP.
Those Perl people would eventually discover mod_perl's power as they
require it, and then they would take the step to "upgrade" to the power of
handlers away from the "missing link".
But without that "missing link" to make things easy for people to move from
PHP to Perl, then Perl will miss something very crucial to maintaining its
standing as the "defacto language for Web applications".
3 years ago, I think it would be accurate to say Perl apps drive 95% of the
dynamic web. Sadly, I believe (anecdotally) that this is no longer true.
SpeedyCGI is not "THE" missing link, but I see it as a crucial part of this
link between newbies and mod_perl. This is why I believe that mod_perl and
its documentation should have a section (even if tiny) on this stuff, so
that people will know that if they find mod_perl too hard, that there are
alternatives that are less powerful, yet provide at least enough power to
beat PHP.
I also see SpeedyCGI as being on the way to being more ISP-friendly already
for hosting casual users of Perl than mod_perl is. Different apps use a
different backend engine by default. So the problem with virtual hosts
screwing each other over by accident is gone for the casual user. There are
still some needs for improvement (eg memory is likely still an issue with
different backends)...
Anyway, these are just my feelings. I really shouldn't be spending time on
posting this as I have some deadlines to meet. But I felt they were still
important points to make that I think some people may be potentially
missing here. :)
