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
