Re: Package proposal: Mail_Mime (alternative)

> > http://www.heino.gehlsen.dk/software/temp/Mail_MimeAlternative-0.0.0.1.tgz > > > As far as I understand it he turned the whole concept of Mail_Mime "upside-down" :-) I my opinion, it's more of a turning it "downside-up" ;-) As I see it, MIME is an extremely flexible container ment to transport wery diffrent data (just as HTTP is), which means the core of a MIME-implementaiton should be flexible enough to used for other purposes than e-mail - just think of how Internet Explorer can save complete pages in one file using priritive MIME. As far as I can se in the CVS, the Mail_Mime package originally lacked a parser(/decoder) part, and its only purpose was to produce MIME-complient headers and bodies. Since then the decoder was added - using the original mimepart class, which might have been fine back when it were not supposed to be returned to the user containing parsed data - and this is in my opinion where someone made a mistake... Clearly I believe the current implementation of Mail_Mime is done backwards - just think of how RFC 2045 defines an entity: "2.4. Entity: The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. [...]". In my opinion it's clear, that the focus ought to be on the entity and not on the parser or composer - and this is why I ended up writing a new package! > But let's see if the API remains the same / was extended. Currently It's the parser/decoder and the entity/part classes is NOT backward compatible, but the composer class 'mime' ought to be. Actually I started with some minor patches etc. to the current package, but it quickly bacame clear, that what I actually wanted was a new decoder / parser - the fact that the decoder had to recursicely create decoder objects to handle 'message/fcr822' is just one example of what I thought was very bad form. Furthermore I also wanted to access the headers within the parts, but they were stored within private variables - and so on. Summa summarum is that I wanted a more advanced and flexible mime package... > He surely should contact the current maintainer for cooperation. If the packages are to be merged I couldn't disagree, but that was actually not the plan from in the beginning - what I originally had in mind was an advanced alternative, but if it comes to it I do believe it's possible and rather easy to make my package (allmost) fully backward compatible. If a merge is what it comes to cooperation with the maintainers of Mail_Mime is of course the best way of handling such a thing ;-). Until 'the list' has spoken I'll think of it as two unrelated packages... > But maybe if we agree that the new features are necessary it would be a > good idea to develop a replacement package with BC API instead of > "trying to turn around all the internas" of the current package. If my package were actually to 'replace' the current Mail_Mime, which have never been my intention, I think making a subclass that adds the backward compatibility would be best. On the other hand, whats the problem of having a simple Mail_Mime and an advanced Mail_MimeAdvanced package ? > Heino, please let us know about the API of your package If it's some phpdoc overview you had in mind, here is is: http://www.heino.gehlsen.dk/software/temp/Mail_MimeAlternative-API/ (otherwise otherwise you have to more specific ;-) > and the feedback from the current maintainers. > Thomas Cox is one contributor - so he might have a deeper view into the current package also. That'll have to wait for now :-)