RE: [PEAR-DEV] Package proposal: Mail_Mime (alternative)

> From: Heino H. Gehlsen [mailto:heino@gehlsen.dk] > Sent: Wednesday, August 20, 2003 10:27 PM > > Therefore it is now your turn to convince other people that your package > > should make it into pear as an alternative. > > 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... Well my first contact with PEAR was writing a merge/replacement for DB. Let me tell you that this is one well established package. In the end it was decided that I should develop MDB as a separate package of DB and that it might replace DB as the default package sometime down the road. So there is value in convincing the community. > 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 comply > 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). Touchy subject. I think we are doing quite well with the lead reigns over hus packages. However I have always been in favour of assigning QA people to each category so that they can make compentent recommendations for all packages in the category. This could help in defining API's across packages and they would also be competent in commenting on situations like these. > 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. > 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... PEAR is not a framework. Regards, Lukas