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

[prev] [thread] [next] [Date index for 2004/12/31]

I'm going to chime in, as someone working on a suite of modules that are
intended to eventually work with apache 1.x and 2.x.  First, I agree with
this:

On 12/31/04 2:27 PM, Adam Kennedy wrote:
> For the moment, I'm asking just that the release of mod_perl 2.0 be put
> on hold until this problem, and it is most definitely a show-stopper of
> a problem, is resolved in it's entirety. And to the satisfaction of both
> the mod_perl developers and the perl community.

Next, I'm going to put in my vote for a new namespace, be it Apache2:: or
something else.

As has been pointed out, the APIs of mod_perl 1 and 2 really aren't
compatible--nor should they be.  Apache 2 (the http server) took the 2.x
change as an opportunity to Do It Better, and so should (and has, for the
most part) mod_perl 2.

Even as someone writing several modules that will need to work with both
versions of mod_perl, I'd still rather have a clean split.  I can abstract
things easier (based on $ENV{'MOD_PERL'} most likely, but many mechanisms
are possible) if there's a clean namespace split.  Let me unify my API.
I'll hide the Apache:: and Apache2:: (or whatever) differences behind the
scenes.

As for third party Apache:: modules, let them eat port.  I'd rather see them
make Apache2:: ports that take full advantages of the brave new world of
MP2.  And I'm sure many (most?) authors would like a chance to revisit their
APIs anyway.

Porting while maintaining API compatibility and staying in the same
namespace seems like work to me.  Porting to Apache2:: and being able to
clean up the sins of the past and do cool new stuff in the process seems
like fun.  Call me crazy, but I think this is a common view among
programmers (in the case of 3rd party Apache:: modules, whether they're the
original authors or not).

Finally, I don't see a proliferation of Apache2_2::, Apache3::, etc.
namespaces as a real threat.  The policy is simple: CPAN namespace == an
API.  If apache/httpd 2.[2-9] or 3.x requires or would benefit from a new
mod_perl *API*, guess what, then you get to pick a new CPAN namespace.  If
not, you can continue to use Apache2:: (or whatever) regardless of how
apache/httpd server changes behind the scenes.

This line of thinking eventually leads to another simplifying decision: the
mod_perl API versioning and branding should be divorced from Apache
Foundation branding and versioning where possible.  If Apache 3.x doesn't
warrant mod_perl API changes, then there's no reason the Apache2:: namespace
can't serve it.  Ah yes, but the "Apache" name is in both places, so that
argues for maybe ModPerl::, ModPerl2:: or MP2:: or whatever instead of
Apache.*::.

My summary:

1. Hold off on the offical release of mod_perl 2 until this is settled.

2. I think the simplest solution is also the cleanest and the most
forward-thinking, even if it is more work: a new CPAN namespace for mod_perl
2, and a divorce of mod_perl branding and versioning from the Apache
Foundation's branding and versioning.

-John



        -- 
        Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html