perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <a...@phase-n.com>
Subject [Fwd: Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN]
Date Fri, 31 Dec 2004 23:58:15 GMT
John Siracusa wrote:
> On 12/31/04 4:40 PM, Stas Bekman wrote:
> 
>>Finally you don't want to use it - don't use it. It's an open source
>>software, it will succeed or fail by *its own merits* and not because the
>>infrastructure has a long known problem but is not willing to evolve.
>>
>>And to repeat this again. If you install only mp2 under the given Perl,
>>all those hours spent in trying to stop the evolution are a total waste,
>>since mp2 has no problem what so ever. None of the problems discussed in
>>this and many other similar threads is relevant. They are relevant only to
>>a few people who for some reason want to have both modperl generations in
>>the same tree. And you will be able to count those with your fingers on
>>the left hand. So let's hurt 99.9% of users, because 0.1% will have it a
>>bit harder than the rest.
> 
> 
> I think the infrastructure thing is a red herring.  Unless the "native"
> mod_perl 2 API is 100% compatible with mod_perl 1 (it isn't), mod_perl 2
> shouldn't be in the same CPAN namespace as mod_perl 1 if mod_perl 1 will
> continue to exist (it will).  This is regardless of whether or not I or
> anyone else plans to have both mod_perl 1 and 2 installed at the same time.
> It's simply The Right Thing to Do, IMO.

And more than that, it fundamentally hurts everyone as it breaks an
entire assumption of the language. Whether 99% (I have yet to see this
number proven, perhaps a slashdot poll?) of the userbase have this
problem "worked around" in the limited case of the application run-time
environment, it STILL causes problems for those using both, AND it
causes problem for ALL of the common perl infrastructure that has no 
choice BUT to hold both for AT LEAST 5 years, more likely 10.

So you get bizarre problems like encountering something funny in your
mod_perl2 program, going to search.cpan.org, or perldoc.com to look up
that module and writing code against that online documentation, and it 
won't work, because the documentation doesn't match the API of what is 
actually running on the system.

Are you, personally, willing to make the decision on behalf of the PMC 
and The Apache Foundation that nobody that uses mod_perl 2 is allowed to 
use any perl website?

You cannot just pile up workarounds that work in a limited set of 
situations for a sufficiently high percentage of the user community and 
expect things not to still go funny everywhere else.

Again, you have addressed ONLY the limited cases of installing for the 
end user, and runtime for the end user. (Assuming that the end user does 
not interact with any public perl resources while doing so).

In addition to that...

GD didn't change API, they changed backends. Other modules have changed 
API and announced that the old one is now redundant. Both are acceptable.

What mod_perl is trying to do is have its cake and eat it too by using
a new backend, AND using a new API, AND saying that the old API is still
supported. This is what you are doing that is unprecedented.

Ideally you would keep a back-compatible API, and the only other 
reasonable alternative is to announce that the mod_perl 1 API is now 
redundant and will no longer be supported. "mp2 is the future, mp1 is 
the past. As of today".

Furthermore, despite trying to resist flaming, but if I can put a number 
of fully described problems in front of you, backed up at least for some 
of them by for all intents and purposes the ENTIRE perl community other 
than you, how on earth can you still disqualify that out of hand.

When EVERYONE is telling you that you might be wrong, don't you at least 
owe it to them to wait before plunging the entire mod_perl world into 
controversy by release something that won't work on the perl 
infrastructure, and that nobody wants?

I would suggest that these sorts of decisions are a call for the 
pmc@perl, rather than any single individual developer on the project.

Firstly, if we should pause to deal with near-universal concerns from 
the perl community. Secondly, if you should end-of-life mod_perl 1 when 
you release mod_perl 2 over the top of it. For starters...

Now I have an 800km drive in 5 minutes. I'll provide some details 
answers to your other comments at the other end.

Adam


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Mime
View raw message