> Do we have an "official" namespace for general-purpose third-party > modules meant to be run under "mp2" ?
Yes, Apache::
[...]
[Ayhan] The reason I thought it wouldn't be good is that :
1) The mod_perl standard distribution comes under "Apache::" and it
might be useful to distinguish what is "standard" and what is 3rd party,
but if mp2-dev doesn't have any problems with that, then it's OK.
What if we the distro decides to adopt some 3rd party modules into the core, like we did with Apache::Reload?
2) Despite all the efforts towards "compatibility", let's face it, a lot
of the "intricate" mp1 modules on CPAN are just downright broken right
now.
Pure response handlers should largely work, but those who tried to
emulate things that mp2 (and apache2) do by design (like filters) are
just beasts to be left -and maintained- in the mp1 world I think. If
90% of the code has to be duplicated in a "if (mp1) {..} else {..}"
statement, I don't think it's worth keeping the same name.
The implementation details don't matter. You could have one file with if/mp1/mp2 branching or two files one of which Makemaker will pick at the install time. Apache::Peek delivers *5* different implementations in the distro. Apache::Scoreboard comes in two different distros. Apache::VMonitor will have one file implementing support both generation (it's rewritten from scratch to use TT and be fully sub-classable).
It all depends on the user API. If as an author you can provide an API which matches mp1 and mp2 versions, than you really really want to keep the same namespace. If your module implements a new user API, then yes, it's quite possible that you will want to give it a new name, at least not to confuse users who may try the old API on the new module. I'm finishing porting Apache::Scoreboard and Apache::VMonitor which will look and feel almost the same under mp2. Same goes for Apache::Request.
This applies mostly to filtering though, where we have seen a real
paradigm-shift. The scope has been widened too : Before it was a
"Perl-only" deal. Now it fits in, and beautifully I must add, to the
Apache layered-IO framework.
Then again, this is my personal opinion, and I'll go with whatever the "official" namespace happens to be. Besides, the "name change" does not absolutely have to be in the "Apache::" part of the name space. It can happen down below, if it has to occur at all.
Let's discuss each case separately and decide what's the best choice for the end user. It's quite possible that a rename is a good idea as I've mentioned in the other thread.
The only problem really is the CPAN support, when two versions of amodule are available. The problem is known and we should get some answers from the CPAN team shortly (there was a CPAN meeting a few days ago).
[Ayhan] What do you mean? One can download any version from CPAN
archives today.
If, on the other hand, CPAN is to automatically detect the installed apache / mp version and fetch the "right" module version or something, that's kind of voodoo and could cause lots of headaches.
That's examctly the problem, as CPAN (and PAUSE) have no notion of supporting several branches/generations of the module. Unless you ask for a specific version number, it'll always fetch the latest one. That's the issue I'm trying to resolve with CPAN folks. Once mp2 is released we are going to have a lot of complaints of people trying to install mp1 and getting mp2 instead.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
