Re: Package proposal: Mail_Mime (alternative)

> > > You may look at the 2.0 folder in the Mail_Mime cvs folder, it's a > > > rewrite of Mail_Mime, experimental. > > > > I allready have looked it through - the code is 6½ months old, and actually > > looks like an abandoned atempt to move forward - the main focus still seems > > to be on the composer class (the decoder is actually missing), not the > > entity/part class which I believe ought to be in focus... > > The composer class is merely a nice frontend to the MimePart class, which is > necessary to make the whole thing usable to folks who have simple needs. 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... > 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. 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. > 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. > 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... > 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? 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 ? As far as Mail_Mime being "a core part of PEAR", I have to protest! It might be a widely used package, but the core and heart of PEAR is in my opinion the PEAR package, the coding conventions, and the idea of collecting a lot of usefull quallity code in a collective repository etc. - not some individual email-related package, that might be widely used, yet not used/needed by the majority! PS Is your answer based on the discussion until now or on a review of my proposed (devel-state) code/package ? Heino