Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The way you've laid it out is not entirely how it went down.

    The problem with the Apache::Request situation was not that they were going to chance Apache::Request 1 to an incompatible Apache::Request 2.

    You would great a major incompatibility, which would mean you had to immediately drop support for Apache::Request 1 (no more releases) and you could only ever have either Apache::Request 1 or Apache::Request 2 installed, you could never have both installed without a completely seperate dedicated Perl install.

    But that has been done before. GD did it. It hurt, but it was their choice. And I for one will never use GD again because of it.

    But the problem was that in doing so, they THOUGHT that they could work around the problem. They thought they could have their cake and eat it too. But they were wrong, and it took a _lot_ to convince them of that.

    The doomed scheme would have ultimately meant changing EVERYTHING else to fit their workaround. They'd already written their own version of MakeMaker, they were starting to write their own version of perldoc (mp2doc!!!), they wanted CPAN changed to suit them, and if they had kept going, we would have seen a gradual expansion to replace pretty much everything with their own versions.

    That was the real problem.

    The point at which things changed was when half a dozen people including me managed to finally convince the mod_perl group that they COULDN'T have their cake and eat it to.

    That the workaround scheme was ultimately unworkable, and that Perl just did not work that way. So the choice they had was either 1. Do a GD.pm, break of legacy support entirely, and go with the complete API change in the same namespace. 2. Do something else (I think I suggested about 5 options at one point) the most attractive of which was moving to a different namespace (Apache2:: being the obvious choise).

    And after much deliberation by the group on the merits, they decided that the level of pain that would be introduced by doing an API change, once the workaround was no longer an option, exceeded the threshold of what they were willing to do to their userbase.

    And so they decided to go with Apache2:: instead.

    The problem was not the API change, it was that the solution to that problem that they'd gone with up until the first release candidate was a bad one.