Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN

[prev] [thread] [next] [Date index for 2004/12/31]

Adam Kennedy wrote:
[...]

[my apologies if I've over-trimmed Adams original, but it's hard to keep 
focused on such a huge email]

>> Why mod_perl2 didn't Rename its API
>>
>> The reason for not renaming mp2 core and 3rd party modules APIs
>> to embed the version number like (mod_perl2, Apache2::Cookie,
>> Apache2::Scoreboard, Apache2::SizeLimit, etc.) is very simple
>> and logical. Even though the internals of mp2 core and 3rd party
>> modules are totally different from their mp1 counterparts, for
>> the most parts the user API hasn't changed at all. Renaming the
>> API is counterproductive, as it'll will impose extra work on
>> the modperl users, and dangerous as the added complication may
>> drive the users away to use other similar technologies which
>> don't have this kludge.
> 
> 
> I agree completely this principle, and it is indeed a positive goal.
> 
> The only point I'm going to make here is that the API has indeed changed
> quite significantly.

Adam, you didn't quote the whole story here. The unquoted parts explain 
that's it's not only the issue with those parts of the API that did change.
http://perl.apache.org/docs/2.0/user/porting/porting.html#Why_mod_perl2_didn_t_Rename_its_API

> Summary: API 2 is similar to, but fatally incompatible with API 1

By reading the whole section quoted above you will see why the above is 
not so as you say.


> 
> ----------------------------------------------------------
> 
> Implementation
> --------------
> 
> While the motivation for maintaining the same API is correct, the
> implementation in its current state would appear to be less than ideal.
> 
> mod_perl2 proposes to use an entirely new technique, one that has never
> before been used in a non-Acme:: perl package, and involves creating a
> parallel module path called Apache2/.
[...]
> Because of this, the method used by Apache2 can most likely ONLY ever be
> used by Apache2 and can never be a more general feature, without serious
> changes to the entire perl module-resolving infrastructure, or a 
> different implementation.
> 
> Summary: The mechanism used by Apache2 is mutually exclusive with any
> other module using a similar mechanism.

The end of
http://perl.apache.org/docs/2.0/user/porting/porting.html#__pm__so__Files_Collision
addresses this issue. Apache2 workaround is needed for those several users 
who want to have both generations under the same perl. 99.9% of users do 
*not* need to use this workaround. So that issue is moot if you ask me.

Talking about generic solutions, if the problem didn't exist, only.pm 
wasn't written http://search.cpan.org/dist/only/
the URL above also explains why we didn't use only.pm


> -----------------------------------------------------------
> 
> API Overloading
> ---------------
> 
> In establishing a parallel module tree that provides a similarly-named
> but different set of modules, the "use Apache2;" statement is 
> "overloading" the entire CPAN namespace at an API level, allowing 
> multiple "stable and supported" but fatally incompatible APIs to 
> co-exist in the same location in the perl namespace.

An important note: Not at runtime!

>  > For example: there are two internally incompatible versions
>  > Apache::Scoreboard (but which otherwise work identically for
>  > users): http://search.cpan.org/~stas/Apache-Scoreboard-2.02/
>  > http://search.cpan.org/~dougm/Apache-Scoreboard-0.10/.
>  > Notice that each generation is developed and maintained by a
>  > different developer.
> 
> Under normal circumstances in perl development, the API is either
> changed, making the previous version redundant. (and potentially causing
> damage in the process) or kept fully compatible with previous versions
> (preferably).
> 
> The concept that an arbitrary number of different APIs should LEGALLY be
> able exist in the same namespace and ALL be considered to be supported
> at the same time is so unprecedented in the perl world that it has not
> even had a name until now.

You must be kidding, Adam. What about GD, SQLite, Sun::Solaris::*, etc.

> For ease of reference, the term "API Overloading" is now starting to be
> used to refer to this idea of having multiple "current" APIs supported
> within a single namespace.
> 
> This sort of technique is much more accepted in the C world, which has a
> much more sophisticated library versioning and linking system with ld
> and .so files.

Agreed. But modperl is definitely not the first module to encounter this 
problem.

>> mp2 provides a Perl API for libapr and libaprutil projects (which
>> can be used even if you don't run modperl). At the moment there
>> is libapr 0.9.x, 1.x and 2.x will be released soon. All those
>> are partially incompatible. Since modperl provides only a partial
>> mapping to the C APR API the mod_perl users so far can run their
>> code unmodified no matter whether they have libapr-0.9, libapr-1.0
>> or libapr-2.0 installed. If we were to embed the numbers in the
>> API, users would have had to rewrite their application to make
>> it support each new release of APR.
>>
>> Let's look at the multiple C libraries you have installed on
>> your machine. 99% of the libraries do not change their API naming
>> when they release a new version. Take for example the Berkley
>> DB library. It had dbopen(3) for its 1st generation, and 2nd, and
>> 3rd, and 4th.
> 
> 
> The critical point I'd like to make here is that the Perl APIs APR:: and
> APR::Util:: are a totally different entity in a totally different layer
> to the underlying libapr and libaprutil libraries, although the two APIs
> have for clarity obviously been named to reflect the names of the
> underlying C APIs used to implement them.

Sorry, I fail to see what's special about this example? It's exactly the 
same as mod_perl. It's exactly the same as with any other module that has 
this problem.

> As a perl module author, we are generally expected to maintain API
> compatibility and stability regardless of the underlying implementation.
> This is encapsulation done correctly.
> 
> If the underlying library changes, the perl author has three choices
> (although he can use a mix of several or all of them).
> 
> 1) Change to the new underlying C API without changing the Perl API of a
> similar name.
> 
> 2) Change the Perl API and make a judgment call on behalf of your user
> base that the damage caused to them from the change is worth the
> resulting improvements to the API.
> 
> 3) Implement a new API, completely different from the first, name it
> differently, and allow the user to use that instead, and convert in 
> their own time.


> Which of these three is done is a judgment call best made by the
> author and/or lead developers.
> 
> The only thing available to the Perl user that helps to provide choice
> over which version (and thus API) of a module you use is the only.pm
> module, which implements API security by saying.
> 
>   "I do not want to upgrade to the versions outside of this known range
> in case the API changes and breaks my code"
> 
> only.pm allows the user to secure the APIs they use against damage by
> the author, by allowing the user to intentionally prevent the use of
> unknown versions of modules.

Right, and Apache2.pm is the same as only.pm, but it's better in the case 
of modperl, as explained at the end of this section:
http://perl.apache.org/docs/2.0/user/porting/porting.html#__pm__so__Files_Collision

[fast forward]

This lengthy analysis fails to identify that this is not a modperl-core 
specific problem. This is a problem of many existing packages on CPAN. And 
trying to point out the finger at the modperl-core instead of spending the 
energy at solving the problem is a waste of time.

> At this point things are getting rather flamey and way too crazy, so I'm 
> going to conclude this email for now.
> 
> I am CC'ing this email to a number of people I think may need to need to 
> be brought in to this discussion, or that could be affected by this 
> issue in a major way.
> 
> I am also CC'ing pmc@xxxx.xxxxxx.xxx, which I believe is the address for 
> the mod_perl management committee? If not, could someone from the 
> committee please forward on.
> 
> For the moment, I'm asking just that the release of mod_perl 2.0 be put 
> on hold until this problem, and it is most definitely a show-stopper of 
> a problem, is resolved in it's entirety. And to the satisfaction of both 
> the mod_perl developers and the perl community.

The following is my point of view only. so other modperl developers may 
think differently.

Unless the other developers vote against, the modperl 2.0.0 will be 
released as soon as the *real* showstopper bugs are fixed. And in my 
estimation that will be the next week, or at most the week after.

It's unheard of that an open source project will be prevented from being 
released, because the infrastructure doesn't support it. And because a few 
folks suddenly decided to wear god caps.

You want to lock it out from CPAN - lock it out. You will only hurt Perl 
by doing that. Don't forget to lock out the numerous other packages which 
live on CPAN with this problem for a long time already. If don't lock 
those out, you can't lock out modperl2.

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.

Happy New Year to every one.

        -- 
        __________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@xxxxxx.xxx http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

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