Solution to the Apache2 issue: Option 3

[Adam Kennedy <ad...@phase-n.com>]

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 
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: Solution to the Apache2 issue: Option 3

[Randy Kobes <ra...@theoryx5.uwinnipeg.ca>]

On Mon, 17 Jan 2005, Joe Schaefer wrote:

> Adam Kennedy <ad...@phase-n.com> writes:
>
> [...]
>
> > 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.
>
> Hmm, can you give more details about this?  So far I only see
> Apache2::SOAP (which is Randy's module, I think) when I
> type "i /Apache2/ " in the CPAN shell.  The other listings
> I see (MasonX, OpenFrame, etc.) have a different package prefix,
> so I don't see an immediate problem with those.

Apache2::SOAP is mine - this was more of an internal thing
for CPAN-Search-Lite that I was using to provide a mp2 SOAP
interface, as Apache::SOAP of SOAP-Lite, as of yet, doesn't
work with mp2. Certainly, if recommended, I'd be open to
renaming this, or arranging for PAUSE not to index it.

-- 
best regards,
randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: Solution to the Apache2 issue: Option 3

[Adam Kennedy <ad...@phase-n.com>]

Well, there are two things here.

What I mean to say was that there is an emerging trend towards people 
using a separate Apache2 module anyway, regardless of whether it is the 
first Apache2:: or it is a web-server-driver type interfacing module 
from something like OpenFrame.

A search on search.cpan.org shows a half-dozen or so Apache2 things.

As to the "locking" of namespaces, I don't believe it is possible, but 
most CPAN stuff like that works quite well by convention.

DBI::, PPI::, FSI:: (another upcoming project of mine) and a few other 
things state explicitly somewhere in the POD that "main namespace is for 
me, you go use ..."

DBI:: -> DBD:: (drivers) or DBIx:: (extensions)
PPI:: -> Perl:: (end-use modules)
FSI:: -> FSD:: (drivers)

So if you want to keep relatively strict control over Apache2:: for 
mod_perl's own use (for the potential Apache->Apache2 option) then it 
might be a good idea to provide some fairly straight forward information 
on this in the Apache2 module, and/or the mod_perl docs.

If of course by "lock" you mean "lock out" as in "we aren't going to let 
you make Apache2:: modules" then I'm pretty sure that wouldn't fly. :)

If Apache2/mod_perl states this clearly, and the majority of people know 
this, then anyone uploading an Apache2:: module without permission is 
going to be jumped on pretty quickly and will generally pull things from 
CPAN quite happily (Like last year when someone uploaded List::MoreUtils 
when there was an existing module List::MoreUtil)

The modules@ list, if they know about it, will also tend to discourage 
people doing bad things along the same lines.

Adam



Joe Schaefer wrote:
> Adam Kennedy <ad...@phase-n.com> writes:
> 
> [...]
> 
> 
>>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.
> 
> 
> Hmm, can you give more details about this?  So far I only see
> Apache2::SOAP (which is Randy's module, I think) when I 
> type "i /Apache2/ " in the CPAN shell.  The other listings 
> I see (MasonX, OpenFrame, etc.) have a different package prefix, 
> so I don't see an immediate problem with those.
> 
> I think that, no matter how the pmc resolves the namespace issue, 
> it will need to exercise some control over the things that CPAN 
> indexes under Apache2::.
> 
> Is it possible to lock the Apache2:: namespace on CPAN somehow, 
> or is that already the case?
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: Solution to the Apache2 issue: Option 3

[Joe Schaefer <jo...@sunstarsys.com>]

Adam Kennedy <ad...@phase-n.com> writes:

[...]

> 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.

Hmm, can you give more details about this?  So far I only see
Apache2::SOAP (which is Randy's module, I think) when I 
type "i /Apache2/ " in the CPAN shell.  The other listings 
I see (MasonX, OpenFrame, etc.) have a different package prefix, 
so I don't see an immediate problem with those.

I think that, no matter how the pmc resolves the namespace issue, 
it will need to exercise some control over the things that CPAN 
indexes under Apache2::.

Is it possible to lock the Apache2:: namespace on CPAN somehow, 
or is that already the case?

-- 
Joe Schaefer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org