mod_perl is NOT PHP. It wasn't meant to be.
PHP allows for embedding a scripting language inside of HTML and allows for some
"neat" things. It is also I believe easier to install and setup then a related
mod_perl server.
Reasons/questions of new users:
1) You have to get all kinds of modules and install them just to get to a usable
environment
(lets face it you can't do much with a fresh install on mod_perl unless you already
know mod_perl)
2) Which embedded perl code should I use if I want one? (Embperl, Apache::ASP,
Mason, etc.)
3) What security module do I use?
4) How do I set up session tracking?
5) What good is session tracking?
6) How do I access a database?
7) How do I get mod_perl to work with x database?
Yes some of this is in the guide, but at some point it becomes to easy just to
point a user a document and assume three things:
1) The guide is written generic enough that users at any level can understand it
2) The "real" question is locatable even if the person doesn't know the "real"
question
3) The guide is in a language that is familiar to them.
I am all for advocating the use of mod_perl, but the basics of setup, install and
usability are always going to be key.
Does anyone have any figures on how long it takes to setup a mod_perl server vs. a
php server?
(correctly, not just running)
Before we determine whether to advocate we need to term what and how to advocate.
I have been using mod_perl on Windows and Linux for the last 3 years. I find it be
an extremely powerful addition to a normal apache server, but the tool kit is too
large and diverse for most people that are simply looking to get a little dynamic
scripting done.
My personal vote for how to advocate, would be better summaries of the various
modules and how they can be used in real life scenarios.
i.e. the thread a few months ago about have a summary of all the embedded Perl
modules (Mason, Embperl, Apache::ASP etc.) outlining their strength and weaknesses
in laymens terms if possible.
We are also advocating the use of Perl which should be much easier since there are
numerous books and example code available in print and online that will work inside
of mod_perl with little or no change.
I just checked out the PHP site and their online manual allows for user comments
that are displayed at the end of each page. Hmm....
Aaron Johnson
martin langhoff wrote:
> kevin montuori wrote:
>
> > additionally, i think that some consideration should be given to
> > how mod_perl is packaged.
>
> I think it's of crucial importance the fact that a distro as widespread
> as RHLinux 6.x had mod_perl messed up. That has forced quite a lot of
> developers that were trying to get their feet wet with mod_perl to get
> in a complex compile sequence. That's a source of 'bad reputation', and
> of php developers, as the included php was old but working ;)
>
> I don't know how messed up are other distros regarding apache/mod_perl,
> but making sure the main distros *do* get it right is paramount to make
> mod_perl catch.
>
> Another item that we should really have is a good (and somehow
> sanctioned) RPM that replaces the apache rpm (or deb) included in broken
> distros. Then we can include in the guide and related pages a link for
> [broken-distro-name] users, so they get a suitable replacement with a
> similar config. That's an important issue, because a redhat user has
> other non-standard modules included in his rpm, such as PHP, and
> compiling a *complete* apache, with mod_perl, php and the kitchen sink
> is a daunting task -- and too high an entry price.
>
> anyway, not an easy task ... mmhhh..
>
> martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
