Re: Package proposal: Mail_Mime (alternative)

> > On the other hand, whats the problem of having a simple Mail_Mime and > > an advanced Mail_MimeAdvanced package ? > > It sounds to me like there are no benefits of Mail_Mime than compared to > Mail_MimeAdvanced? Personally I have absolutely no opinion about the naming i this case, but since I'd like to move the files into Mail/Mime/ (or even just Mime/ if one might be as bold as to say, that the MIME RFC's could be used for much more than just (e)mail) instead of the current location in Mail/, I find it possible that both versions could coexist (even under the same packagename). > The way you were explaing the changes the performance > would even be better in your package (correct me if I misunderstood > you?). Well, I haven't done any benchmark testing... Since it's written in PHP instead of within PHP, I believe the performance can never be 'even be better', but in the hope of improvements I have done a lot of parsing by reference internally. The vision is to make the Entity class able to store itself into multiple files for later reuse, so performance improvements have honestly never been on the top of the wishlist, but that doesn't meen that one doesn't care about it, does it ?-) > If all that you add is power flexibility and possibly even better > performance while being able to maintain almost complete BC it sounds > like a prime candidate for a new major version jump for Mail_Mime. Currently BC is completely broken since it's a rewrite from scratch, but i believe BC could be achieved at a acceptable performance loss.