This is meant to be a sort of absolutely minimal solution, that involves as little change as possible and is more about containment of the problem than fixing it.
It provides an option for the case where the PMC decides there is simply nothing that can be done due to timing issues and the expectations from the community of a quick release.
Rather than to fix mod_perl2 core itself, the goal instead of to mitigate the problems on a wider scale, and limit them to just the core package as much as possible.
For convenience, I'll label it Apache2-Modules.
In essence, it assumes not just that the core mod_perl package is not going to be able to change in any way, but also that the workarounds (despite their sheer number) can be made sufficient _for_the_core_package_.
However, it would appear that the same problems apply for the 318 other Apache module, and are significantly more difficult to fix.
Applying the same arguments from the primary Apache->Apache2 solution for applying a namespace change when there is an incompatible API change (and optionally also for a generational change) most of the problems can be mitigated by moving the other 318 modules to Apache2, or at least giving them the option too.
This solution has the advantage that it a) Works with CPAN b) Requires only documentation changes to core mod_perl c) Gives the 100 Apache:: authors choice over their migration strategy.
The documentation for the mod_perl2 core relating to recommendations for other Apache:: authors would be updated to something similar to the following.
----------------------------------------
As an author of an Apache:: module, you have several options when moving to mod_perl 2.0.
1) If your Apache:: module has not changed its own API, and is able to both install and run compatibly with both versions of mod_perl using the same distribution tarball, you are recommended to keep the same Apache:: name for the module.
2) If you wish to do a rewrite of your Apache:: module with a new API or architecture to take advantage of new features in mod_perl 2, you are recommended to use Apache2:: and provide the new module as a separate distribution.
3) If you wish to upgrade your Apache:: module to mod_perl 2, but cannot do it compatibly and within the same distribution tarball, you should be aware that having two different modules with the same name currently causes significant problems with CPAN and other common perl infrastructure. The recommended solutions at this time are to either pull support for the mod_perl1 completely and remove it from CPAN, or to move the new version of your module to Apache2::.
Regardless of the whether you move to Apache2:: or not, all Apache:: modules are recommended to include a section in their POD documentation similar to the following, immediately following the =head1 NAME section.
=head1 COMPATIBILITY
Apache::Module is compatible with both mod_perl 1 and 2.
---OR---
=head1 COMPATIBILITY
Apache::Module is compatible with mod_perl 1 only.
See L<Apache2::Module> for the mod_perl 2 specific version of this module.
----------------------------------------
... or something along those lines.
At the moment there would appear to be an assumption (or at least, I get the impression) that all of the other Apache:: authors have to follow the same technique and solution.
If mod_perl itself is not to be fixed, and we accept that it is too late to fix the problem in any way, the next best solution would be let the other 100 AUTHORS know that they are allowed to move to Apache2:: as a solution, with a set of circumstance-based recommendations.
It may well mean a little initial confusion for the people installing modules, but as long as the Apache:: modules shove their compatibility information right in the faces of anyone that cares to look, I don't think this will be a problem.
Incidently, it appears that this is already starting to happen in CPAN, with a number of authors uploading Apache2 modules to specify they work with the mod_perl 2 API.
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
