perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gunther <gunt...@extropia.com>
Subject Re: mod_perl presence at OSCON (and other CONs) is at danger
Date Wed, 09 Jun 2004 02:29:49 GMT
I am not responding solely to your post here, but also to several other 
points I saw brought up.

Geoffrey Young wrote:

>Perrin Harkins wrote:
>  
>
>>On Tue, 2004-06-08 at 18:47, Chris Shiflett wrote:
>>    
>>
>>
>
>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 Registry.pm 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.
>
>
>  
>
I apologize in advance if because of my mass snipping I've taken you out 
of context.

While I think you are right that mod_perl is more than that, I do wonder 
what people really care about. I have to say that although I love the 
speed of mod_perl, I find that for most tasks I have to do, I do not 
require even a persistant perl interpreter. I just like using Perl.

I've only used the Apache API a few times and that was when I was trying 
to emulate Sybase's WebSQL and hoping to convert all our Sybase WebSQL 
apps to mod_perl at a past organization I was at. If it weren't for the 
peculiar ways in which WebSQL did it's stuff, I probably would have just 
as soon run with Apache::Registry. So I suppose I would be in that camp 
that frustrates you. :)

I like using Perl or mod_perl for web apps because I know that Perl can 
be used as a cron job, as a scripting language, as a glue, for sysadmin 
tools already written in Perl (eg log_accum.pl) etc. I feel as if I 
learn PHP then I would have to still learn Perl for the non-web stuff. 
So why not kill two birds with one stone?

One thing I found interesting was Perrin bringing up the idea of 
different ways of using Perl. I still think that there is a key here. 
However, it's again I wonder about what is really mod_perl specific PR 
and what is perl specific PR.

Unless I am mistaken, I think Bioinformatics was brought up in this 
mailing list as one possible class of apps to talk about here. Here 
actually, I am not sure mod_perl really shines relative to Perl. 
Bioinformatics apps tend to call algorithms or statistics that may run 
for such a long time that adding the small amount of time it takes for 
Perl interpreter to load on a reasonably recent Linux box is really not 
noticeable.   It's nice to use mod_perl, but not something that makes 
people scream if mod_perl isn't on a typical bioinformatics web server 
which usually emphazises small number of PhDs running complex algorithms.

It has always seemed to me that mod_perl shines more for apps that are 
retail or heavy in usage where you need to accommodate many hits and 
each hit does something very small that would be terrible for a 
slow-down to occur (like amazon front page or a porn site). I am not 
sure if this is another "issue" about PR for mod_perl -- why use it if 
machines are fast enough to support plain CGI/Perl these days? Perl 
saved the Human Genome Project. mod_perl didn't, although maybe mod_perl 
saved more than one slow webstore?

With that said about bioinformatics in particular, I think I would carry 
the idea of classes of apps one step further. I think the key to 
mod_perl being noticed is really about the apps not about touting the 
technology. It's one level of PR to claim that a website that is popular 
like Whatever.com is using mod_perl, but quite another for whatever.com 
to share their code so that others who want to do the same thing 
download the code and use mod_perl because the app said "use mod_perl".

To me, it seems PHP has a lot more apps touting the use of PHP (even if 
indirectly) than mod_perl apps do. There are a lot of free Perl apps out 
there, but mod_perl apps.... on perl.apache.org tI count about 15 apps 
total (not counting "toolkits" or core "tools" like CMS systems). This 
is part of a chicken and egg problem. On the one hand, if you have a lot 
of apps, you are more likely to see adoption of the technology and if 
the technology is well adopted, you are likely to see a lot more apps.

Along with the apps is the convincing of the ISPs to support mod_perl. 
How many support PHP (A lot I would gather?) and how many support 
mod_perl? I gather it's about 50 from the directory of ISPs on the 
mod_perl site, but how actively do they really support mod_perl? Do they 
support it? Or does it come by default along with PHP with every single 
shared user www account someone gets for the going rate of 9.99$/month?

Another issue...

has anyone gone to the following URLs:

www.modperl.com -- a website for the "first" book but the link to the 
real modperl site is actually buried way down as one of the links
www.modperl.org (some consulting firm called powerdata?)
www.mod_perl.com (doesn't exist)
www.mod_perl.org (doesn't exist)

For PR, I would think it would be nice for common URLs such as these to 
be freed up and appropriately used or redirected to perl.apache.org

As an only semi-frequent user of perl.apache.org, I really prefer typing 
www.modperl.com or .org and not having to remember the *.apache.org 
convention.  Call me crazy, but even though I use pubmed several times a 
week, I still find myself just typing www.pubmed.com instead of the real 
url: http://www.ncbi.nlm.nih.gov/entrez/query.fcgi.  Similar concept.

Gosh, I guess I am being very negative in this email. Sorry if I come 
across that way.

I could be wrong, but I suppose a positive way moving forward would be 
to resolve the following issues to generate more positive PR for 
mod_perl in the following summary:

1) Promoting classes of applications that use mod_perl
    eg Success stories for classes of applications that use mod_perl 
(maybe even bioinformatics)
     a once a month "interview" with someone using mod_perl successfully 
would make a nice repetoire of more stories.
2) Promoting applications that use mod_perl
   If you've written a useful app that uses mod_perl at your workplace, 
please see if your employer would consider allowing it to be open sourced.
3) Let's get the domain names in order.
eg It's nice that Lincoln and Doug have had modperl.com all these ages, 
but now that their book has been out for years, it would be nice to give 
the URL back to the community and instead have their book use a more 
appropriate URL like modperlbook.com. Likewise for other URLs.
4) ISPs That support mod_perl
  This is a tough one but I think it would be interesting to know what 
supporting mod_perl means for the 50 ISPs on the list. Is there a way 
that they can share their secrets (ala #1) to encouraging other ISPs to 
support mod_perl. Can people evangelize the use of mod_perl on their 
servers? I suppose this may only happen if there are enough apps in #2 
to force the ISPs to want to enable mod_perl by default though...
5) Create a google bomb whereby when "web apps of mass domination" is 
searched, perl.apache.org comes up. Then report the google bomb as a 
news item on slashdot. 

I guess I should stop my spewing now. I wish everyone here luck in 
promoting mod_perl.

Thanks,
   Gunther


Mime
View raw message