perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <>
Subject Solution to the Apache2 issue: Option 3
Date Mon, 17 Jan 2005 02:22:33 GMT
OK, alongside 1) Apache->Apache2 and 2) Parallel-Perl solutions here is 
a potential third solution for people to ponder over.

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 


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 

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.


Apache::Module is compatible with both mod_perl 1 and 2.



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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message