Re: Package proposal: Mail_Mime (alternative)

> > http://www.heino.gehlsen.dk/software/temp/Mail_MimeAlternative-0.0.0.1.tgz > > What's the difference to the current Mail_Mime? Ups, sorry - I might have been kind of late ;) First of all, the the counterpart to the core of the decoder, is split up in multiple functions, so it's easy to extend the parser. For instance one can now overload a dispatcher function, which controls which kind of parsing the current part need to go through depending on the mimetype - and therefore one can easily add support for currently unsupported or local mimetypes. Furthermore the body-encoding/decoding is now separated from the parser allowing reuse in other packages (the current package actually has the encoding and decoding places well hidden in two diffrent classes). The parser doesn't waste time on first parsing the headers into an assoc.array, and then reparseing them into a nested assoc. array - all header-parsing is handled in the Header class which, just like the Message class that the Entity (Part) class extends, can be used by any mail-related package. The reason for extending the Message class is, that if the Message class somehow became the standard handling of messages, an Entity/Part could function as a drop-in for any mail-related send-function which normally accepts a Message object. If one uses the Message class's setMessage() function on an Entity object, it'll simply use the parser and replace itself with the result of the parser - this feature is again provided for so an Entity object will always be compatible with an Message object.. Of cource UUencoded sections can now be extracted automatically from the body and reinserted as parts as if they were originally mime-attachments (though a minor bug currently deletes the origianal body). The entity class itself now internally handles what getMimeNumbers used to do, and it's actually possible to use the IMAPv4 fetch body syntax (TEXT, HEADER, 1, 1.MIME, 1.2.TEXT, 1.2.5 etc.) to get the wanted parts. Since I personally don't use the xml-functions, I haven't looked into that kind of stuff, but it's my plan to implement some kind os save-/restore-feature in the entity, which will allow one to save an entity in separate files, and only reload the needed parts. There is no longet this 'the constructor can be called statically' feature, since it actually did created an instance of the class anyway, and thareby fooling users (who hadn't looked into the code) to believe it's cheaper. Since it was the parser/decoder implementation I originally got tired of, this (and the entity class) is where my focus has been - so to the mime-composing class is only a mere modification with the absolutely needed changes to make it play along with the new Entity class - I'd like to see some of the composer class rewritten, but for now it should work as usual from the users point of view. This proposal is not a drop-in for the current Mail_Mime (at least not in the current development state ;), and of course the implementation could be more complete, but for now the basics is there - hey, I thought it was about time I got some constructive input from those of you who have an opinion... Heino