On Fri, 26 Aug 2005, Octavian Rasnita wrote:
Some advocacy ideas:
I think that there are a few groups we should target:
- The programmers/net admins that are already using mod_perl, but older
versions (Macromedia is using Apache 1.3 and mod_perl 1)
- the programmers that already know perl but they are using only CGI scripts
- The programmers using other languages like PHP, Java, ASP...
1. The users of older versions of mod_perl
- It is important for them to see that it is very easy to upgrade to latest
version of mod_perl.
- It should really be easy to upgrade to mod_perl. Maybe some scripts that
automaticly make all the replacements could be helpful.
- Maybe some short tutorials about how to upgrade Apache 1.3 to Apache 2 and
mod_perl 1 to mod_perl 2 would be helpful.
- It is important to explain why mod_perl2 is better and why Apache 2 is
better. (Without Apache 2, they won't have mod_perl 2).
- It is not important to explain them that perl is good, or that mod_perl is
good, because they are already using them.
2. The programmers which are using only cgi scripts
- It is important to explain why mod_perl is better than cgi, and make some
speed comparisons (telling that it could be x times faster)..
- It is very important to explain how easy is to install mod_perl.
- They need to be tell that the simple cgi programs can run using mod_perl
with no change.
These are great suggestions ... Many of these points are
addressed in the docs under http://perl.apache.org/; for
Win32 specifically, Apache2/mod_perl-2 offers a very
significant performance increase.
[ ... ]
Most of those who are not using now mod_perl but are using a computer, are
probably using Windows, so there should be very easy for them to install
mod_perl under Windows.
(I think this target group has the most chances to bring more mod_perl
users, and after using Windows as a test machine, most of them will probably
use it under Linux)
Many know this already, but for the archives, for those
Windows uses that want to get started right away,
there's all-in-one binary packages that include mod_perl:
http://perl.apache.org/docs/2.0/os/win32/install.html
In particular, the Perl-5.8-win32-bin.exe at
http://www.apache.org/dyn/closer.cgi/perl/win32-bin/
contains an Apache 2 / Perl-5.8 binary with a httpd.conf
configured with a sample mod_perl Registry script,
a mod_perl handler, and example HTML::Mason, Apache::ASP,
and Template-Toolkit pages.
As for installing mod_perl with an existing Apache/Perl
installation, apart from ppm, there's also a script:
http://perl.apache.org/docs/2.0/os/win32/mpinstall
that will take a user through a dialogue to install the
appropriate mod_perl version.
Many users don't know that apxs can be installed under Windows, so that
installation kit for apxs for Windows should be included in all the versions
of mod_perl, promoting that mod_perl can be installed easy under Windows.
When building mod_perl under Windows, an option is presented
to the user to install a Win32 apxs, if it's not present.
It's not mandatory to do so, however, and probably shouldn't
be, as apxs isn't necessary to use mod_perl, and the number
of required components should be kept to a minimum.
Most perl users under Windows are using Active Perl, and the default ppm
repositories of Active State should include mod_perl.
They should also include all the necessary modules which are not installed
automaticly by mod_perl (those from Apache:: and Apache2::).
This question has arisen in other contexts (eg, installing
GD). ActiveState comes by default only with their
repositories configured, and I can appreciate why - they
add a ppm package to their repository only if it can be
built unattended and all the tests pass, including those
of any dependencies. It then becomes a question of quality
control - packages in other repositories may not necessarily
have passed all their tests, for example. ActiveState does
though, in the ppm FAQ, include a list of other repositories
that are available.
Anyway, PHP will increase in popularity much faster because it has some
advantages perl doesn't have, so this fight won't be easy.
Perl would be better if:
[ ... ]
- If all the modules from CPAN will be able to run under all operating
system, including Windows, and all those modules could be installed without
needing a C compiler installed.
Some perl modules cannot be installed using the cpan shell under Windows,
and give errors when trying to install them, but they don't need
compilation, and if they are copied manually in the perl tree, they are
working fine. I heard a few programmers telling that perl is a bad language
because they have tried some modules from CPAN and those modules were not
working fine.
(Of course, most of them probably tried them under Windows).
Once one is used to it, installing things is pretty easy
with ActiveState's ppm utility. Of course, one problem
is that not all possible CPAN distributions have an
associated ppm package, but usually, if one asks, someone
can make up a ppm package of a missing distribution (if
it can "easily" be built under Windows and "most" of the
tests pass).
--
best regards,
randy
