perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Leszczynski <lar...@emailplus.org>
Subject Re: mod_perl presence at OSCON (and other CONs) is at danger
Date Wed, 09 Jun 2004 02:46:06 GMT

On Tue, 8 Jun 2004, Geoffrey Young 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.

I agree with Geoff on both points above, but in my experience the things
that are obvious and important to us as mod_perl programmers are not
necessarily the primary considerations for choosing a platform when a
project is ramping up (even if they should be).  Designs are not always
well thought out, and future development of projects can't always be
predicted, so sometimes it might only be in hindsight that you realize
that you have a need that could have easily been satisfied by the
power/flexibility of mod_perl but not necessarily by the platform you
chose (assuming you didn't choose mod_perl in the first place...).

What I have seen is people initially choosing a platform because it
quickly meets the needs of a prototype or proof of concept, and then that
chosen platform ends up being what's released in production.  When you
want to get a proof of concept up and running quickly, you might tend to
look for systems where it's quick and easy to implement common
infrastructure tasks like: managing user sessions, managing database
connections, handling config files, and logging.  This lets you
concentrate on your application code, which is the interesting part.  For
example, I've spoken with people who said they chose PHP or ASP for the
initial implementation of a project specifically because they thought it
looked like it would be easy to handle sessions and/or do database coding,
and they assumed it would be sufficient for the rest of the application
stuff they needed to do.  We mod_perl people know there are (many)
straightforward solutions for those kind of infrastructure things, e.g.
Apache::Session::*, Apache::DBI, Config::IniFiles, and Log4Perl,
respectively.  But I don't think it's obvious at all to newbies or
outsiders that those kind of things are available or easily implemented.

So getting back to an idea that appeared early in the thread, it would
probably be good to have something like a centralized, well-documented
"toolkit" of code/modules/patterns (not sure the best form that would
take) that could be quickly hooked together into a skeleton application.
I know all the pieces are out there, maybe it's just a matter of figuring
out the best presentation...


Larry


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Mime
View raw message