Loading ...
Sorry, an error occurred while loading the content.

62765Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN

Expand Messages
  • Jared Rhine
    Dec 31, 2004
    • 0 Attachment
      > Stas> 99.9% of users do *not* need to use this workaround. So 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
      > box.

      I would like to support Randal's contention (if not his tone) that
      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
    • Show all 37 messages in this topic