Re: Package proposal: Mail_Mime (alternative)

> > This is due to historical and BC purposes as it fit with the PEAR Mail > well. > > I actually don't see how returning the body and storing the header > internally fits well with then Mail package (I know about the change in > 2.0 - and I never said the complete message should be returned as a string, > if that's what you thought...) Then yuou should look at the sample Mail documentation to see how it works: http://pear.php.net/manual/en/package.mail.mail-mime.example.php > > > Actually I believe the those classes should not only be in separate > > > classes, they should but in separate packages... > > > > I don't. That would be overkill. > > And the other email-related packages, which could easily implement a common > header class, were of cause to use the MIME-enabled header class even though > MIME is of no interest to the package? What's the problem in seperating the > header class from Mail_Mime, and make a MIME-clean Mail_Message package (or > perhaps implement it in Mail) ? It's not too much to ask for a package that wants to use a header class to install the Mail_Mime package. If they did this then they'd also get access to base64/qprint etc encoding/decoding capabilities (assuming thats the way things end up. > If one has to break BC, i believe one should no longer talk about mature > code, since the code has only proven to be mature for so long! Of cause > that's only my humble opinion... Just because an API will be broken doesn't mean the code behind it is all brand new. In fact 99% of code in 2.0 will be the same, it will be simply, better implemented. > > > If so, what is your opinion on having two diffrent > > > Mime-implementations in PEAR (which was actually my original idea) - a > > > simple one, and a advanced and extendable one ? > > > > My opinion is not to have two. > > Well, that's fine with me, but it really would be nice with a little > constructive dialog - until now I have only gotten the first impression, > that you have shown my proposal absolutely no interest, and if that's the > case just say so, and I shall never bother you or your package again! (then > you can have maturity and I can have functionality ;) If spending time looking through your code and writing responses to you consitutes no interest, then fine. Had I felt your code was the way forward, then you would have my support. I don't however, so you don't. > > > PS Is your answer based on the discussion until now or on a review of my > > > proposed (devel-state) code/package ? > > > > Both. > > Well then, the package has only been downloaded 4 times (3 of them at 15. > aug.), so unless it was somebody else who downloaded the package proposal > just 8,2 minutes before I recieved your initial message, I would strongly > erge you to spend a little more than 8,2 minuttes on evaluation of such a > package before you reject peoples work in favor of your own unrealized > project - had this been my first experience with PEAR, I would presumably > have canceled my proposal and lost all interest in the development of PEAR. I have spent a lot more than "8.2" minutes looking at your code, surprisingly enough, since Friday. > Just to make myself perfectly clear here: I have absolutely no problem > having a proposal (my code) rejected, and I'm absolutely not interested in > starting something unplessant here - but if the case is that a proposal like > this is allmost silently rejected by the lead after a 8,2 minutes long > review without further explanation, I am actually offended as a user of > PEAR! If you don't mind having a proposal rejected, you should try not to sound so indignant when it happens. -- Richard Heyes V-webmail - http://www.v-webmail.org