title: mod_perl Advocacy

=head1 Thoughts about scalability and flexibility

Your need for scalability and flexibility depends on your needs from
the web.  If you want only a simple guest book or database gateway
with no feature headroom, you can get away with any
EASY_AND_FAST_TO_DEVELOP_TOOL (Exchange, MS IIS, Lotus Notes, etc).

Experience shows that you will soon want more functionality, that's
the point you'll discover the limitations of these "easy" tools.
Gradually, your boss will ask for increasing functionality and at some
point you'll realize that the tool lacks flexibility and/or
scalability.  Then your boss will either buy another
EASY_AND_FAST_TO_DEVELOP_TOOL and repeat the process (with different
unforseen problems), or you'll start investing time learning how to
use a powerful, flexible tool to make the long-term development cycle
easier.

If you and your company are serious about delivering flexible Internet
functionality, do your homework.  Then urge your boss to invest a
little extra time and resources to choose the right tool for the job.
Your long-term Internet site will prove the results.

=head1 The boss, the developer and advocacy

Each developer has a boss who participates in the decision-making
process.  Remember that the boss considers input from sales people,
developers, the media and associates before handing down large
decisions.  Of course, results count!  A sales brochure makes very
little impact compared to a working demonstration, and demonstrations
of company-specific and developer-specific results count big!

Personally, when I discovered mod_perl I did a lot of testing and
coding at home and at work. Once I had a working heavy application, I
came to my boss with 2 URLs - one for the plain CGI server and the
other for the mod_perl-enabled server. It took about 30 secs for my boss
to say: `Go with it''. Of course the moment I did it, I have had to
provide all the support for other developers, that is why I took
time to learn it in first place (that is how this guide was born!).

Chances are that if you've done your homework, you've learned the
tools and can deliver results, you'll have a successful project.
If you convince your boss to try a tool that you don't know very well,
your results may suffer.  If your boss follows your development
process closely and sees much worse than expected progress, he might
say "forget it" and wish never to give mod_perl a second chance.

Advocacy is a great thing for the open-source software movement, but
it's best done quietly until you have confidence that you can show
productivity.  If you can demonstrate to your boss a heavy CGI which
is running much faster under mod_perl, that may be a strong argument
for further evaluation.  Your company may even sponsor a portion of
your learning process.

Learn the technology by working on sample projects.  Learn how to
support yourself and learn how to get support from the community; then
advocate your ideas to your boss.  Then you'll have the knowledge;
your company will have the benefit; and mod_perl will have the
reputation it deserves.

=head1 A summary of perl/cgi discussion at slashdot.org

Well, there was a nice discussion of merits of Perl in CGI world. I
took the time to summarize this thread, so here is what I've got:

Perl Domination in CGI Programming?
http://slashdot.org/askslashdot/99/10/20/1246241.shtml

=over 4

=item *

Perl is cool and fun to code with

=item *

Perl is very fast to develop with

=item *

Perl is even faster to develop with if you know what CPAN is :)

=item *

Math intensive code and other stuff which is faster in C/C++, plugged
in into Perl with XS/SWIG and transparent to perl user of the modules.

=item *

Most CGI apps do text processing, where perl excels at

=item *

Forking and loading (unless code is shared) a C/C++ optimized CGI
produces an overhead

=item *

Bandwidth is a bigger bottleneck than perl performance (vs C/C++) (not
true for Intranets, and might change for Internet in a number of
years)

=item *

For database driven apps, db itself is a bottleneck.  lots of posts
talk about latency vs throughput.

=item *

mod_perl, FastCGI, velocigen and perlexec are good solutions for plain
mod_cgi slowness

=item *

other light alternatives to perl and its derivatives mentioned: PHP,
Pyhton

=item *

well, there were almost no voices from the M$ and alike technologies
users, I guess that's because they don't read /. :)

=item *

many said that in many people's minds: 'CGI' eq 'perl' > 0 (the
entropy of perl grows bigger :)


=back



=cut

