Re: Package proposal: Mail_Mime (alternative)

> > 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 I've allready read both the sample AND the code (as I've allready said, I have studied your package closely), and I still don't see the point in returning the body in this way - nor do I get how it's so perfect for Mail::send(). And if the current implementation is not just a little bit weard, why do you plan to drop the returning of the body in v2.0's build(), and only make the header and the body accessible the the user via mothods? > > 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 > > thoughMIME 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 MIME is to be so tightly integrated in all the other packages, the then MIME should be integrated into the Mail package! You said that having a Mail_Message package would be overkill - how is that diffrent for Mail_Mime, if it is needed in email-related package because of the placement of a common header class. If a header class are to be in the same package as the MIME-stuff, the MIME-stuff should be with the one to move in with the header class - not the other way around... > If they did this then they'd also get access to base64/qprint etc > encoding/decoding capabilities (assuming thats the way things end up. Why not also include the uu, xx and binhex encoder/decoder's while at it - even though they are not directly related to MIME at all ? Whats so bad about having a clean header class i the Mail package which Mail_Mime could extend - this way users are not forces to accept encoding and decoding of their data if they don't need it. What I'm actually looking fore here is an implementation of interfaces for both headers, bodies and messages, but to preserve BC with PHP4 an abstract class would have to simulate the interface for quite some time. This way you could have your own MIME enabled header class, I could have mine and somebody else could have their non-MIME header class - but all of them would be compatible with Mail::send(). I actually believe that PEAR is currently suffering from the lack of official cordination between diffrent packages in the Net_* - especially packages that handles mail. I also believe this is something that should be discussed by all the leads of mail-related packages in the very near future, so we could have an official standard way of handling mail. Please don't take this the wrong way, but I personally don't believe that things like a common mail interfaces that concerns many packages should be in the hands of the lead's of packages like Mail og Mail_Mime only - it should be joined effort between all the leads of the mail-lelated packages! > > 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. Preserving 99% percent of the code would only allow modification of 13 lines ;-D I honestly don't know how you would fix all that easily fixable stuff in v2.0, if you only want to make minor alterations to the code, but I now see why you want to go for a major update - it's needed to allow breaking BC. > > > > 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. Spending time looking throug the code of somebody else of cause constitutes intrest, but how is one to know that the code have actually been read, if nothing is written about the code at all ? I only stated how my first impression was. Your first response was rather short and said more about your own code that about mine - that's in fact why I asked if it was based on the discussion alone. The negative attitude towards my proposal was not written directly, but was hidden in the way you focused on the future of your own v2.0 code. In your second response you still only spoke of your own code and plans for a v2.0 - and the quote from your own file only made me wonder, if you had read the code at all. Still speaking of your own code you say that the issues are easily resolved in v2.0 (btw it's so easy, why haven't we seen anything yet ?). It was first in your third mail, that you actually said directly, that you did not like my proposal. Personally I experienced your two first emails as some kind of "try to read the code, comments and manual once more, then you might understand it" message. Since you haven't given any details at all about what it is you don't like about my proposal, I can only asume, that you disaprove with my proposal as a whole. Since the mime class has only been modified to function with my my actual proposal, the entity and parser class, I actually don't care about what anyone think of it, but what about the other individual classes? Is it in fact the whole concept as a whole you dislike, or what? You haven't said anything except that you don't feel it's the way to go, but other MIME-implementations seem to think it is, so what exatly do you think is the way to go (except from preserving mature code) - in the long run? > > 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. I actually hoped that was the case - had it not been, I would have been quite disapointed ;) > > 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. Please remember, that I have actually never said that it was you who downloaded the package just 8.2 minutes before I recieved your message, and that my comments clearly states, that it's how I'd feel, _IF_ you had spent only 8 minutes on reviewing the code including writing the email. Honestly I'm quite releaved, that it was not the case! Actually my proposal haven't been rejected acording to the official woting system - until now it has only been commented. Keep in mind that my original proposal is to have an alternative MIME package, which implements all the stuff i think you have left you, but if you had wanted to merge the code it had been quite wellcomed. For now I'll asume that you'll give a -1 if people began to vote (even though it's still a devel state package) - but right now I'd rather like to know what it is you dislike about my proposal... Heino