Re: Package proposal: Mail_Mime (alternative)

On 15 Aug 2003 at 15:12, Heino H. Gehlsen wrote: > > > > > 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" ;-) [...] > > 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... [...] > > 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 ? Okay then I got you wrong in that point. I thought you wanted to exchange Mail_Mime, a stable package - which would only have been possible if the maintainers of Mail_Mime agreed and total BC existed. Having the idea of a Mail_MimeAdvanced (or maybe Mail_Mime2) would be a good idea. Generally I'm no friend of having Mail_Mime2,3,4,5,6 etc. - but if the API was a bit too narrow designed as Heino said then maybe it's time to allow a Mail_Mime2. But we should be very careful that *escpecially* this package will be mega-flexible that we can extend it to anything else that might come up in the future. Stefan