62765Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN
- Dec 31 4:09 PM
> Stas> 99.9% of users do *not* need to use this workaround. So thatI would like to support Randal's contention (if not his tone) that
> Stas> issue is moot if you ask me.
> Four out of my five biggest customers *will* need to have both
> modperl1 and modperl2 in the same Perl installation tree on their
> development machines, because they'll need to start looking at how to
> port their work over, and they won't want to duplicate-install all the
> other modules they use into two different Perl installations on one
indeed, in real-world mod_perl commercial situations that I'm familiar
with (say about 8), 80% of those real-world users will want to have both
mod_perl 1 and mod_perl 2 installed concurrently due to the
generally-accepted production practice of "if it ain't broke, don't fix
it". By virtue of being actual mod_perl, they already have production
mp1 installations. They will also want to be moving forward with
leading, new releases for development of new systems, that is, mp2.
In any case, Stas, I found myself frowning when you first put out that
"99.9% not a problem" number, and given the testaments given here, we
can at least say "everyone's just guessing" what the real number is.
Perhaps Randal should be thanking Stas for the potential conflicts, as
it's fair to say that consulting fees can increase from confusions and
complications arising from the mp1/mp2 transition. I do believe it's
uncontested that with common configurations and proposals, simulataneous
mp1 and mp2 installations will not be straightforward. People committed
to mod_perl system will muddle through without doubt. New users won't
generally see issues regardless of which docs they read. Though people
who say extra hurdles don't help the community much have a point.
On the gripping hand, I've never thought of mod_perl setup and
administration as very intuitive or inherently robust. People who
figure it out at all are generally already a notch or two above <panders
to the crowd here> and have learned to read documentation.
As a result of mod_perl's multi-step setup, I've long been very careful
during new mod_perl setups. For a number of years now, I've been using
private installation trees such that 0% of my commercial clients will
have any mp1/2 issues as they use private, snapshotted installation
trees to achieve high stability and service isolation. My modern
installations if fact, generally use scripts which download, unpack,
build, and install private installations of Apache, mod_perl,
librequest, HTML::Mason, and even Perl itself with hundreds of modules
from CPAN installed, all into a self-contained directory tree. Config
files, log/state files, and the docroot(s) go outside this tree.
Without revolutions in the mod_perl/Apache/CPAN space, this "private
installation" approach is one of the few likely to provide really
stable, isolated concurrent instances of mod_perl. It should be noted
that mod_perl is not the only "application server" to suffer this
problem, and the same things should be done for python 2.x, the Java
multiverse, and PHP 4/5 web/SOA instances whenever availability,
isolation, maintainability, and testability matter.
Disk space is cheap.
For my part, I'd put forth that one acceptance criteria of whatever mp2
release approach is adopted should be "it should be hard to clobber an
existing installation by being careless with an mp2 installation".
Going forward, I'd ask the community to remain respectful, proposal and
evidence-focused, with an eye rough consensus and working code. There
have been both shining examples and dismal failures thus far in the
- << Previous post in topic Next post in topic >>