perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <>
Subject Re: [mp2] taking a step back?
Date Tue, 04 Jan 2005 08:30:53 GMT
To the list:
Again, I've brought this back in, which wasn't meant to be private in 
the first place, but was mis-sent.
I'll try to keep everything as transparent as possible in future.

Stas Bekman wrote:
> Adam Kennedy wrote:
>>  >> 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::*
>>  >
>>  >
>>  > -1 to embedding numbers in API

To those catching up, here is the general solution for why Apache2_2:: 
won't be necessary.

>> We aren't embedding version numbers in the API, we are embedding the 
>> API  in the module name. documents two APIs. The 
>> "Apache mod_perl 1 API" and the "Apache mod_perl 2 API".
>> And as such, you would have the Apache:: namespace for the mod_perl 1 
>> API, and Apache2:: for the mod_perl 2 API.
>> It's the API revision that is determining the module name, not the 
>> implementation version.
>> Apache::  -> mod_perl 1 API ( Apache 1.0, 1.1, 1.2, 1.3 )
>> Apache2:: -> mod_perl 2 API ( Apache 2.0, 2.2, 2.4, 2.6... )
>> As long as you do what everyone else is expected to do and maintain 
>> API stability, you can keep using Apache2:: regardless of what happens 
>> to the underlying Apache server.
>> The only reason to have to use a new namespace would be if you plan to 
>> incompatibly break the API every single time Apache goes through a 
>> revision.

Please note by "incompatibly" I mean "fatally incompatible". That is, a 
complete change. Small API changes are expected and people can generally 
deal with this.

>> You aren't planning to do that are you? Now THAT would REALLY piss off 
>> the user base.
> Why have you chosen yourself as someone who knows what thousands of 
> other people think?

Because I've done enough programming, and met enough developers, and 
talked to enough people on this issue to say it. Many many people are 
saying these things.

>>  >> or ModPerl::* namespace, or perhaps just something different
>>  >> under Apache:: (eg, Apache::Utility).
>>  >
>>  >
>>  > That's wrong, Randy. What you gonna do when mp2.2 is released, 
>> which may
>>  > happen any moment, now that Apache 2.2 is getting ready for its 
>> release.
>>  > Rename those again? And again for 2.4? ...
>> You keep asking this, and to my distress noone else form the perl 
>> community seems to have answered you.
>> You use Apache2::... it's the same API and it's going to be unchanged 
>> when Apache 2.2 comes out, and when Apache 2.4 comes out. You might 
>> add a few new features, but it's normal to add features to APIs. It 
>> doesn't break anything.
> That's exactly why I'm saying that you don't understand the 
> Apache/modperl internals. The change from 2.0 to 2.2 might and will be 
> incompatible for certain features. So if we do Apache2 we must do 
> Apache2_2, and so forth.

Then if you choose to make small changes, you document them. This is 
quite normal. It doesn't require API changes.

The only time you need to move to a new namespace, it is because you are 
   going to break EVERYTHING, as has happened with mod_perl 2.

If you had kept mod_perl 2 completely compatible with mod_perl 1 you 
wouldn't need to use Apache2:: at all, and we wouldn't be in this situation.

>>  > -1
>>  >
>>  > mp2.2 will have
>>  >
>>  > Don't forget that you will need to rename as well
>> If the APR:: perl API doesn't change, you don't need to change the name.
> That's very inconsistent. So you will have a mix of Apache2_2/Foo and 
> Apache2/Bar in the same distro? That's insane.

APR:: is a separate library and a separate API, or so I believe. I'll 
look at this later, but I'm curious what the reason was for not 
packaging APR:: separately, so that applications that need APR:: but 
don't need mod_perl don't have to install apache.

>> Yet again you summarily dismiss the perl community.
> I'm sorry, I fail to see the whole perl community presented by a few 
> individuals. I don't dismiss the community, I disagree with those few 
> individuals.

As I said before, I listed a number of people willing to be named in 
public, and I also indicated that I have not yet encountered a single 
person who supports API overloading or "multiple incompatible stable 
APIs in the module name".

>> I'm not just making this shit up.
>> Perl on the web is ALREADY being marginalized by PHP. At the low end 
>> where convenience and installability matter FAR more than performance 
>> PHP has been kicking our ass for several years now.
>> It's getting harder to find decent people because every bloody person 
>> seems to be starting their web-stuff attempts with PHP. And it's hurting.
>> mod_perl is still very useful for big projects, but PHP is eroding 
>> from the bottom.
> And the thing you and Randal have started are doing a fantastic job and 
> bringing it further down. You should enroll to PHP as an achievement gift.

What we have done so far is not in the general public eye, it's on 
product specific mailing lists. I wouldn't be doing this if I didn't I 
had to.

Taking no action on this will be far worse than taking action.

>> If mod_perl is going to get even worse to install, and the standard 
>> perl tools don't support it, and installing the CPAN modules is going 
>> to be a pain, if not impossible, we are going to lose even more of our 
>> userbase.
> I disagree with that. But you know that already.
>> I wrote the rant offline and it's outlines a solution path I _really_ 
>> don't want to follow. He's since emailed me offline, and as long as 
>> the mod_perl community is willing to pause for long enough for people 
>> to get back from holidays and discuss this properly, I see no reason 
>> to start getting desperate.
> Eh? What's that?

Since I've had a few people emailing me to say that I should be 
addressing the whole community and that you are not the one that has to 
make these decisions, at this point I'm going to hold and wait for their 
interaction on this subjects.

I'll outline my next steps only if it appears people aren't going to 
wait and talk amicably. Because then things start to get worse and I 
don't want that.

I'm willing to trust that the general mod_perl community will see that a 
pause and proper communication if a better option.


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

View raw message