perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <a...@phase-n.com>
Subject Re: [mp2] taking a step back?
Date Sun, 02 Jan 2005 06:32:34 GMT
Randy Kobes wrote:
 > As probably with most of you, I'm getting worried with the
 > tone of the discussion on the mp2 namespace problem, and the
 > directions it's heading - getting locked out of CPAN, etc.
 > And, rightly or wrongly, getting a a sizeable fraction of
 > the Perl community upset on the eve of the official mp2
 > release can't be a good thing ... Also, though, like Joe
 > raised, it's upsetting that a good portion of the flames are
 > directed at Stas, who has put so much into mp2, both inside
 > and outside of the actual code.

Stas, as the leader (or at least lead developer) of the project, is 
naturally going to attrack some level of flame, especially from those 
that are themselves fairly hot, like Randal. (and I know he won't mind 
me calling him a firebrand) :) I've been flamed by him for controvertial 
ideas a few times myself.

What is causing the biggest issue for me, as someone who as a rule 
_never_ gets involved in these kinds of things in public, is that he is 
willing to immediately and completely discount the opinions of everyone 
else, whether or not they are trying to have a reasonable discussion or not.

And what is SCARING the HELL out of me is that he is not even willing to 
wait for a few days or weeks to have a proper discussion with those of 
us who _are_ reasonable most of the time.

(BTW, I apologise for my previous outburst, but I to leave my New Years 
Eve party early and go back to work still somewhat drunk in order to 
deal with this before my long drive yesterday)

He seems to have fully committed to the release, no matter what problems 
are found or what anyone, including some of his own development team, says.

While there are around 8-10 items I would personally consider to be a 
major concern, there are 2 of these that are absolutely fundamental 
problems that you can't just release and find workarounds for later.

These problems are

1) Perl does not allow and cannot support multiple API versions in the 
same module name to be considered "current". You MUST choose between 
end-of-life'ing the old one immediately, or use a different name. 
mod_perl2 appears to refuse to pick either of these.

2) API overloading (parellel module trees) means that you lose support 
for the entire of the Perl public infrastructure. This will cause major 
problem for ALL of your userbase, who are also one of the three main 
groups of OUR userbase.

These two are bad things. Bad bad bad bad bad! On these two problems I 
can safely say that the entire of the perl developer community agrees 
with this.

The rest of the problems are largely symptomatic and I'm happy to ignore 
them if we can resolve these two. Most will vanish if we solve these2 
any ANY of the 5 or 6 possible ways I think it can be done.

You cannot just bluster though these objections, or assume they will go 
away, as stas would appear to be doing.

Shutting your eyes and singing "la la la la", or attacking the 
messengers will not help you get past these problems.

Whether it is bullheadedness, or a cognative dissonance given how close 
mod_perl2 is to release, I can't say.

But this is what is causing stas to get most of the flames here, 
compounded by his position as the figurehead for mod_perl 2.0.

 > The fundamental issue of using the Apache::* namespace for
 > modules both in mp1 and mp2 sounds like an unresolvable one.
 > On the one hand, at the level of a script or handler,
 > Apache::Request (for example) in mp1 has a lot of the same
 > interface as Apache::Request of mp2. However,
 > Apache::Request itself built under mp1 can't be used under
 > mp2, and vice-versa.  A lot of this worry seems to be
 > directed at potentially bad recommendations of the
 > CPAN/CPANPLUS shell - this could be addressed by PAUSE
 > supporting generations in the future (near or far), or it
 > may have to wait until perl6, but from the sounds of things,

Perl 6 may indeed be able to solve some of these problems in a different 
way.

 > nothing along these lines will be probably be done in the
 > near term (ie, the next few months); even if Autrijus comes
 > up with a workable proposal in the next month, implementing
 > this, on PAUSE or elsewhere, would take some more time
 > (especially given Andreas', and others', views on this), and
 > then it would be longer to get workable clients out there.

The perl "standard timeframe" for moving to new systems like CPANPLUS or 
Module::Build or PPI (once I finish it) is around 2 or 3 years, with at 
LEAST 5, preferably 10 years before we stop supporting it altogether.

Ideally, we try to maintain back-compatibility forever. Perl 6 will 
still support much perl 5.004 code.

As a point of reference, the current "minimum perl version support in 
CPAN" debate is over whether it is acceptable yet to have 5.6 as a 
standard minimum version, and that has been out for AGES. For the 
record, I'm on the side that says authors should still support 5.005 
unless you have no other choice.

All of Perl culture tried to be back-compatible indefinately, if 
possible, and to only break it for good reasons. And when we break, to 
break completely.

 > Although this may not be the best time to raise this, the
 > strong opinions being expressed, plus the shortness of time
 > on the part of the many of us, perhaps we could look at what
 > would be involved to move the modules in the mp2 core so as
 > not to conflict with mp1. If I counted right, there's not
 > that many:
 >
 > Apache::Log
 > Apache::PerlSections
 > Apache::Resource
 > Apache::SizeLimit
 > Apache::Status
 > Apache::URI
 > Apache::Util
 >
 > Putting aside for the moment the relationship of these to
 > their mp1 counterparts, it shouldn't be too hard to come up
 > with alternate, descriptive names, either in an Apache2::*
 > or ModPerl::* namespace, or perhaps just something different
 > under Apache:: (eg, Apache::Utility).
 >
 > The question of mod_perl.pm itself is different. In the mp2
 > distribution, in a sense this is used to "brand" the whole
 > package - give it a version, and a pod NAME and description.
 > Although I see Stas' argument about not having a mod_perl.pm
 > and mod_perl2.pm in the same package, what about just
 > renaming mod_perl.pm to mod_perl2.pm? And in keeping with
 > the use of mod_perl.pm to give an abstract that
 > search.cpan.org can use for the mod_perl distribution,
 > renaming the mp2 distribution itself to mod_perl2. If one
 > sees the use of mod_perl.pm as just representing the
 > package, then calling it mod_perl2.pm may not be too
 > unnatural, given that Apache1 modules are fundamentally
 > different from Apache2 modules.

Although not a universal thing, and not really definitavely provable, 
the preference does seem to be that we should use Apache2. That seems to 
be the "view of the common man" as far as I can tell.

It makes support simple and is completely logical from a user 
perspective. Apache treats it as a different product., distro package 
names say apache2, why shouldn't perl modules be Apache2::. It makes 
complete sense to go looking for an Apache2:: version of any current 
package you are using, like say Apache::GTopLimit, when moving to the 
new server.

If you can't find it, you might look at the old one to see if it is 
compatible, but it's a simple common sense rule that everyone would 
expect as soon as they had seen it once. It's a SIMPLE rule, and doesn't 
require 40 paragraphs of documented workarounds to follow.

 > There's at least two questions that immediately arise with
 > this. The first - how much physical work would it be to do
 > this renaming? Quite a bit, I imagine, but a finite amount -
 > I'd be willing to set aside some time in the immediate
 > future to work on this. The bigger issue is how such a
 > change would affect existing 3rd party code that currently
 > uses mp2? This may cause quite a bit of headaches -
 > "legally" I guess one is free to do this, since mp2 isn't
 > officially released yet, but one doesn't want to alientate
 > existing users.

I actually suspect (although obviously I can't prove it) that it would 
be far less than the work the early adopters have already done. A simple
s/Apache::/Apache2::/ would get you a significant percentage of the way 
there, if we could agree on a recomendation to move to Apache2::.

And most early adopters I've talked to don't seem to mind if it means 
they are allowed to use search.cpan.org again, and perldoc, and man, etc 
etc...

And frankly, early adopters accept going in to their efforts that 
mod_perl2 is NOT a stable product, and changes might happen at some point.

That's why only 1/6 of mod_perl servers as using the new one, and the 
5/6ths who don't want to risk it haven't started porting at all yet.

I'm more concerned about hurting the main body of users, the early 
adopters are smarter and far more capable of handling it than the 
conservative users.

 > I fear, though, that if mp2 gets
 > marginalized, even in the short term, by a (sizeable)
 > segment of the general Perl community, this would be a
 > bigger long-term problem for early adopters. This might not
 > happen, of course, but is it worth the gamble? Perhaps, as a
 > stop-gap measure, one could make up a compatibility layer,
 > similar to Apache::compat, that would assist in the
 > change-over.

I think we can actually do more than this!

Apache::compat works already, yes?

So if mod_perl2 API is in Apache2::, and Apache::compat is altered to 
let Apache:: work as normal on mod_perl2, it means that mod_perl1 
applications and mod_perl2 applications can work alongside completely 
cleanly WITHIN THE SAME Apache 2 server.

This would seem to give us (although admittedly, at this point, with 
some amount of work) COMPLETE upwards compatibility!

Think of the level of adoption of Apache 2 this would drive if most 
people don't have to change their code immediately, if they are willing 
to accept a (small?) speed penalty. This lack of Apache 2 adoption is a 
huge concern at the present yet?

I can't prove this is possible, but I'm sure someone from the mod_perl 
development team could demonstrate if this is possible, or impossible.

In fact, given what would seem to be the possibility to massively Apache 
2 uptake, compared to the current scheme restricting mod_perl2 uptake,
I'm going to CC the Apache Foundation committee in from here on in if it 
looks like the release is going ahead anyway and I have to keep 
escalating my response, past just talking.

 > The question of Apache2.pm then also arises, as,
 > theoretically, if such changes were made, Apache2 wouldn't
 > be needed.

And we also wouldn't need mp2doc, mp2cpan, mp2pod2man, the special 
MakeMaker implementation, the version of only.pm implemented inside 
Apache2, and all sorts of other things you could just delete outright.

 > A couple of people have mentioned that they like
 > Apache2 just as a way of separating mp1 stuff from mp2 -
 > given this, we could keep Apache2 in there, but make it
 > optional (and, perhaps, recommended in the case of an
 > existing mp1 install). That would make the transition
 > easier, but also satisfy the concerns raised about mp2
 > *necessarily* breaking existing tools.
 >
 > As Stas has emphasized, doing this to the core modules
 > doesn't address the broader issue to 3rd party modules. It's
 > probably reasonable to assume though that these developers
 > would understand why this was done, given the strong
 > opposition and the desire to have mp2 supported as much as
 > possible in the standard Perl environment.

Indeed, one of my other 6 concerns is that regardless of any damage you 
cause yourselves, some of the decisions you have made for mod_perl2 
arn't constrained to just you, they force many of the authors of other 
Apache:: down the same path, and lock THEM out of the standard Perl 
environment (both system and the internet tools) as well.

I checked some numbers on this this morning. There are currently 318 
perl distributions in or related to Apache:: that build on top of core 
mod_perl. If their authors (which includes me for PPI::Format::Apache) 
follow the recommended and DOCUMENTED method for upgrading to mod_perl 2 
and use this "use Apache2;" mechanism without also simulataneously 
supporting mod_perl 1 in the same package, THEY will have to be locked 
out of the standard Perl environment as well. This is going to be very 
confusing and piss them off a lot.

There is currently (I think) one package locked out. The uninstallable 
nightmare that is Meta::.

We really really really don't have to have to lock out 300 or so packages.

We end up with the effect of confusing and annoying the very developers 
you are trying to "not confuse" by sticking with Apache::

 > Again, I raise the above not necessarily because it's the
 > best solution within the mp2 environment, but because of the
 > pretty strong opinions expressed on the other side. I'm
 > also, frankly, worried about the wider implications and
 > effects raised about this namespace problem outside of mp2
 > if we don't do this, and as Adam said, getting into a cycle
 > of outwardly spirallying workarounds to solve yet other
 > problems we haven't anticipated. It may be better, from the
 > point of view of keeping peace within the community, making
 > these changes now, and wait until "official" support for
 > generations is in place (which seems to be acknowledged as a
 > real need, both for mp2 and others), either in perl5 or,
 > perhaps, perl6.

You are right about the need.

Support for SOMETHING like generations, at least to prevent ever having 
another situation like the nightmarish GD changeover will almost 
definately be created at some point. Possibly even for perl 5. This is 
the shiny bauble that has caught Autrijus' eye, so it may well happen.

That is, solving "radically different implementation of the _same_ API, 
that you can't just upgrade to automatically".

The support for changing an API without making the old one immediately 
unsupported is far worse, and may well not get solved, even in Perl 6 
(although given Damian is on the case, I wouldn't put it past him).

You need to decide if you want to immediately abandon support for 
mod_perl 1 when you release mod_perl 2. (Frankly, I think this is almost 
a rhetorical question).

And finally Randy, thank you for you and Joe staying calm during this, 
it makes my life a lot easier. Between myself, Autrijus, Andreas, 
Randal, and Schwern, (and others) I'm certain we can work together on 
this and provide advice that can help mod_perl2 avoid the problems it 
currently has, and maybe make it even better.

(Now I have to go write a response to Stas' rather dismissive and 
agressive email, and I'm afraid I'm need to going to have to lay out in 
no uncertain terms what the worst case scenarios are going to be if this 
goes ahead and I have to escalate to the next stage. I apologise in 
advance) :(

Adam

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


Mime
View raw message