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. > > TheMimePart class could be used by itself if so desired, giving your > > entity/part focus. > > When I talk about the lack of focus on the entity class, I'm NOT thinking of > how the users could focus on the class, but the development of the class. > > 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. 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. If they want that, they can use MimePart directly. > 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. > > Certainly the code in the 2.0 subdirectory needs completing, > > 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... > > with things like separated out base64/7bit/8bit/qprint classes and a > header class, > > 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. > > though I feel this is the way to go as it's very mature code and a core > part > > of PEAR. > > 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 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. > PS Is your answer based on the discussion until now or on a review of my > proposed (devel-state) code/package ? Both. -- Richard Heyes V-webmail - http://www.v-webmail.org