Everybody
This whole call for mod_perl advocacy is definitely a good thing. But we're
not going to get anywhere unless we understand the problem in detail. We can
run around all we like talking numbers and touting the virtues of mod_perl
but it's not going to actually do anything unless we address some fundamental
issues. I don't claim to know the answers to these problems, but I do think
I can at least start the ball rolling the right direction to get others
thinking about what next.
If we're on this list, there's a good chance we think we have a good
understanding of mod_perl. Or at least a good understanding of the parts of
the massive mod_perl beastie that we use. I use it all day every day but
don't claim to know anything about Authentication, for example. I'm sure I
could read the chapters in the eagle book and figure it out, but I don't know
anything about it now.
So, making that assumption, I want to bring up a few issues that I see as
crucial.
1. We are worried that mod_perl is not being adopted as a server technology
in enough places. This is actually TWO problems, not one, and to treat is
as one is missing the point. There are TWO different kinds of developer out
there. The first is someone who is probably not a programmer by trade, but
has picked up CGI and/or PHP/ASP programming from a "21 days" book or by
reading through examples. There are a number of reasons why *these* people
have not jumped all over mod_perl... I'm sure we all know what those reasons
are. The second group of people are *engineers* (or *developers*). These
people need something different out of mod_perl. They need good docs,
examples, stability, community support, and FOUNDATION CLASSES (more on this
later)
2. Perl
Let's face it, we love Perl, but a lot of people don't, because *they don't
understand it*. Remember, a lot of people might have looked at Perl 4 when
it was a disastrous hodgepodge and not looked at it since. Perl 5 is an
infinitely better language than 4, but most people don't know that. In order
for Perl to be acceptable in larger institutions with an already-established
software engineering group, changes to Perl itself need to be made. See more
below.
3. Installation/setup
Ok, so if you have Linux, it's a piece of cake... download all the sources,
follow the README's, and go. But what if you don't have Linux? Or you
aren't root, and what if you need access to httpd.conf to keep changing
stuff? And developers are going to need to cycle the server all the time, so
they need the ability to do that, too... it's definitely a weak point. I can
install any one of the Java-based web application frameworks and be
developing immediately.
4. Isolation
A lot of mod_perl projects (or even Perl projects in general) tend to be
one-person shows... maybe I'm wrong, and I'd love it if people could correct
me! But in my observation, we have a lot of programmers working in
isolation. This is bad.
5. Foundation libraries
Because of the open nature of the CPAN community, there are a lot of great
modules floating around out there. However, there is no real API consistency
in them, and this will cause newcomers to Perl a fair amount of trouble.
Moreover, we're not going to get anywhere in the enterprise if people insist
on using HTML templating systems that allow the embedding of code within
HTML. It's straight up and down a total disaster and no right-minded
software architect would ever consider it.
which brings me to...
6. Engineering
The Perl community is made up of a truly eclectic group of people, which is
an amazing strength. However, it's also an amazing weakness: I get the
impression that very few programmers in the Perl community spend a lot of
time *reading* books on software engineering and techniques thereof... and
that lack of knowledge tends to bleed over into a lot of code out there. We
have a HUGE problem in the community of the "coder superstar" mentality...
which is very dangerous. Perl allows far too many tricks, and often code
ends up totally unmaintainable and unreadable because some coding yahoo put
in some glory-code. It happens in many languages, true, but Perl is the
ideal environment for it.
--> SO <--
I hope you guys can give these points some thought. I could be "smoking
grass" but I think I'm on target on most of my points and I'd love to hear
what you guys think too. In the meantime, here are some ideas that might go
down well (or not!):
* We implement a "mode" under mod_perl, kind of like "use strict", that
suddenly forces Perl to behave well from an object-oriented standpoint. By
this, I mean taking some of the power away from Perl that causes trouble,
like allowing anyone to write instance data on an arbitrary instance of a
class...
* We "homogenise" some foundation classes. This means we create a *suite* of
classes that have consistent API, are designed together as a framework, and
are easy to learn
* We need to drop-kick DBI out of the park... it's not that it's bad (it's
actually great... kudos to the DBI crew) but kind of the opposite; it's so
easy to use that most people don't think beyond it. How many of you have
ever thought about implementing an Object-Relational middleware layer using
mod_perl? We could create a set of generic OR classes as part of our
foundation framework.
Well? Anybody?
Cheerz
Kyle
--
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
