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 [EMAIL PROTECTED], 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:[EMAIL PROTECTED] 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
