Re: Package proposal: Mail_Mime (alternative)

> However it seems to me that Richard explained his reasoning. Richard has explained his opinion on why to move forward based on his own current code, but I have not heard a single comment about what's wrong with my proposal - it's even code in development so the API could easily be subject to changes, and any comments would be most wellcome - positive as well as negative... > I would therefore not say that his -1 is "unfair". It's not the '-1' I think is unfair - if that's Richard's opinion the -1 it's most wellcome! What I find unfair to the community is that a package maintainer publically rejects proposed code in favor of his own without as much as a single comment about what's wrong with the proposed code - if an alternative to a package suddenly apear, it might be because the current package doesn't satisfy the need of everybody! While Richard is entitled to have both opinions and plans the least he could do is to tell the rest of us what he really think is wrong with the proposal (instead of just saying that his own plans are the future), and it would actually have been nice if the argumentation on why not to have an alternative implementation (even though it meets some need of a group of users) had been in the open. Personally I no longer care about such comments - I don't know Richard and can personally easily live without knowing his opinion about my code, but within the teamwork on which I thought PEAR relied, I would have expected more than 'I like my own code and plans better, and PEAR will have to wait until I have the time to move on'. > 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... 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). 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...