[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: survey
From:       Randy Kobes <randy () theoryx5 ! uwinnipeg ! ca>
Date:       2005-08-30 16:30:28
Message-ID: Pine.LNX.4.63.0508301056210.2118 () theoryx5 ! uwinnipeg ! ca
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]