Re: Package proposal: Mail_Mime (alternative)

> > Well, that's one of my points, the composer is necessary if the whole > > thing is to be usable - the mimePart was never designed to be the usefull > > and accessible class for the not so simple needs... > > From the comments, right at the top of the file: > > * What is it? > * This class enables you to manipulate and build > * a mime email from the ground up. > * > * Why use this instead of mime.php? > * mime.php is a userfriendly api to this class for > * people who aren't interested in the internals of > * mime mail. This class however allows full control > * over the email. > > Sure it has some issues, but these are easily resolved in 2.0. Please don't take this the wrong way, but excuse me - I could do some cut&paste quiting too! I have in fact read that comment, and I wouldn't have gone as far as proposing an alternative package, if I hadn't studied both the RFC's and your implementation (as well as others) intensively first!!! Of cause it's true that one is allowed 'full control over the email', but due to the amount of code one has to produce (with the risk of messing the hole entity up, if one doesn't know the RFC's) to make even simple modifications to the entity shows that the class is in fact not so straight forward for those without a masters degree in the MIME-implementation. It's still a fact though, that there is absolutely no public mothods or variables to interact with the entity - except for the addSubPart() method - so if the the development of v2.0 has not come further that the current code in the '2.0' directory, there is a very long vay ahead!!! > > Of couse the mimePart class could be used by itself, but only as a mere > > container. One would have to code everything by hand, because of the lack > > of interaction methods in the class - it's simply not designed for direct > > interaction (most of the interesting data is even 'hidden' in private > > variables (prefixed by '_')). Currently the decoder actually only returns > > a stdClass containing the data, so the mimePart class is actually ONLY used > > when composing something new, and then it's not even returned for usage or > > visible to the user - users of the composer class have to combine the > > header and the body at a later point, because the get() method stores the > > headers i within the object for later retrieval and only returns the body. > > 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...) Speaking of the Mail package, imagine if Mail::send() accepted a common message class (used by every email-related package) which the entity could inherit - then sending an email/entity would be quite easy! > And since the composer class is supposed to be an easy frontend to users, > they really don't need to see the MimePart structures at all. Hey, I'm not saying it's a bad thing to hide the entity from the user if exposure is not wanted, but what about the more advanced users? Should they not be allowed to use a simple composer for the simple stuff, and then continue working on the entity directly? > If they want that, they can use MimePart directly. So it's either blindfold or the hard way ? > > Most of > > the central 'content-' header data is not even easily accessible - for > > instance when users compose something new, they have to set the encoding > > manually from the outside of the mimePart class (as do the decoder), same > > for content-type, content-id etc. > > Don't know what you're referring to here exactly, but by the sounds of it it > will be fixed by MimePart 2.0. Well, I believe that header fields like Content-ID and Content-Disposition is often quite essential, but how are one to access them if they are well hidden behind private variables and lack of methods ? > > If it's to be a major release, I agree to the fullest - but if you only > > had touch-up's in mind, I'd suggest you only did a minor update to 1.3. > > Well 2.0 is a major release number... Now that is a nice way of saying 'no thanks for the input, but I'm the lead!'. > > 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) ? > > I'm not sure if I'm misunderstanding you, but are you saying, that what > > you feel is that the future lies in the the curent files in the '2.0' directory > > because of their historical maturity, and that backward compatibility > > ultimately has to be 100% preserved, even if a much more flexible > > alternative could evolve? > > The 2.0 code *will* be a more flexible approach. The code maturity is an > important factor, BC less so as it will be broken. 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... > > 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 ;) > > 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. 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! Heino