perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: mod_perl presence at OSCON (and other CONs) is at danger
Date Wed, 09 Jun 2004 00:29:19 GMT

Perrin Harkins wrote:
> On Tue, 2004-06-08 at 18:47, Chris Shiflett wrote:
>>Another reason for the naming habits is that PHP runs on more Web servers
>>than Apache, and only the Apache SAPI is called mod_php.
> This is exactly the same situation as Perl.  Perl has SAPI support on
> IIS through PerlEx, lots more through FastCGI, and runs persistently
> with any server that supports CGI via PersistentPerl.  (AFAIK, PHP has
> no equivalent for that.)  This is part of why I think singling out
> mod_perl, as opposed to talking about Perl's speed and SAPI support in
> general and giving mod_perl as an example, is a questionable tactic.  If
> you include all of the above groups, you have a lot more friends
> (ActiveState) and reference accounts (

well, I think it really depends on what you want to accomplish.  all the
above really seems like just a perl versus php (or $web_language) debate:
both run on a number of different server platforms, have strong followings,
and are proven scalable and "enterprise" (sorry for throwing out that term,
but you get the idea :).  in the end, arguments like the above are very,
very important ones for us as perl programmers, but I don't think they help
mod_perl prosper as a technology, which is what I'm interested in :)

while I realize I'm in the minority with this view (and perrin and I have
had this discussion/friendly disagreement before :) what _I_ like about
mod_perl cannot be satisfied by anything other than mod_perl - I like the
Apache API, and I would prefer to use it in conjunction with Perl rather
than mess around with C (or even something like apache_hooks, since I don't
know php :)  for those that share a love for this particular aspect of
mod_perl and have a desire to see it prosper, nothing else will really do.

if mod_perl is just a means to performance ends similar to the other
technologies you mention, it would be simpler and more efficient to strip
mod_perl down to just an embedded interpreter and support development of
just and the minimal API it requires.  I think mod_perl more
than that, and that is why I feel beaten down when nobody seems to care
about mod_perl for what it really is, or people say you can just swap it out
for FastCGI or something and things move on.  that's when I feel like I'm
wasting my time.


Report problems:
Mail list info:
List etiquette:

View raw message