Re: Package proposal: Mail_Mime (alternative)
| From: | Greg Beaver | Date: | Wed, 20 Aug 2003 20:42:26 +0000 |
| Subject: | Re: Package proposal: Mail_Mime (alternative) | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-20177@lists.php.net to get a copy of this message | ||
Heino H. Gehlsen wrote:
Personally I don't want to spend/waste my time on trying to make somebody else accept any of my code if they don't aprove of it, and even if I did, It wouldn't matter becuase what I would really like to see is a common standard between every mail-related package (including Net_NNTP which I'm currently working on), and that requires a general agreement among a lot of us. If maintainers of central packages like Mail_Mime (or Mail) believes that such common features/classes are to be a part of their packages, but don't have the time or are not willing to implement them, I don't see the point in having the rest of us agreeing on a standard when they are not going to be implemented in the most central packages for a long time...I still think there must be a single person in charge of each package, who ultimately makes decisions. Your idea of a group will allow the group to override a veto on a personal decision regarding API, if there is disagreement. It doesn't always work in the US, but that check and balance (1 leader, a congress to bully him, but he gets ultimate veto, and they can overturn it) is great most of the time.
This episode has made me rethink the whole thing about the lead's 'owning' the packages, and I believe it could be a serious problem in the future. If PEAR are to become an enterprice level repository, I believe that no individual maintainer should 'own' any packages, and that only extremely well written code should be accepted (some allready accepted code should either be rewritten or droped), and that backward compatibility with the current implementations should not be a goal itself (even though many users allready rely on the code). I believe that there should be made groups that worked on diffrent parts of the repository - every mail-related packages should belong a mail group, every networking (excl. mail-related) package should belong to a notworking group etc. These groups should then define official (API-)standards that every package within the group should complyThis is a great idea. It will introduce a new level of political struggle (who will lead each group?) which may slow some things down, but the added people attracted to make the group do what they need will guarantee at the least a more useful package.
with - every mail-related package should be required to return the data in the official way (so that users of e.g. Net_POP3 should be able to switch to Net_IMAP or even Net_NNTP in a moment). Furthermore I believe PEAR should be placed in a directory (of cause called 'PEAR') to prevent the users from accidently breaking PEAR by having their own DB, Net, Mail and OS directories - alternative repositories could then also use some directory.This is a brilliant idea, one of the best I've seen in a long time.
Summa summarum is that multiple repositories could be used at the samt time! PEAR is currently both a repository AND a framework, but if PEAR as a framework is to be widely used within diffrent repositories I believe that PEAR should know its place as a equally leveled repository...Agreed. PEAR 2.0, anyone?