Re: Re: Ajax PEAR package
| From: | Alexey Borzov | Date: | Thu, 14 Jul 2005 08:20:02 +0000 |
| Subject: | Re: Re: Ajax PEAR package | ||
| References: | 1 2 3 4 5 6 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-38641@lists.php.net to get a copy of this message | ||
Hi,
Sergio Carvalho wrote:
This is a problem without solution. Because of the no-overlap rule in package acceptance, there is no way PEAR can guarantee it contains the best implementations for any given package. Packages are evaluated once and only once, at acceptance time. This is so clearly wrong I can't understand how the no-overlap rule is so widely accepted. While I do understand the reasoning behind disallowing two packages for the same purpose, I am of the opinion this is a serious PEAR flaw. This effectively removes competition, which is one of the primary forces behind OSS quality.It is a misconception, there is no hard "no overlap rule" in PEAR. The only part of the docs dealing with overlapping functionality is the FAQ [1] and it states the following: ========== *There is no problem with competitive packages*, but we want to avoid pollution with 10 template classes, 7 different mail classes, and 3 different layers for databases doing the same only with different function names. First of all, do a reality check: Why do I want to commit a new package? Really bad answers are "To see my name in PEAR" or "I didn't understand the API of the existing class". A good reason for a new class is often, that you are missing a function, behaviour or speed in an existing implementation. In this case, you should take a look at this class, if it possible to extend this class. If not, then you have a good reason to commit a new class. "If not" means, it isn't possible to add the required functionality without changing the basics of this class. ========== If a new package is vastly superior to the existing one, it has a good chance of being accepted, the classic example being Image_Graphite [2]. Of course, there are some PEAR developers who would like to enforce the "no overlap" rule no matter what, but in reality they don't have rules / precedents to back up their claims. [1] http://pear.php.net/manual/en/faq.competitive-packages.php [2] http://pear.php.net/pepr/pepr-proposal-show.php?id=145