On Thu, 2007-10-11 at 19:49 +0200, Philip Van Hoof wrote:
> On Thu, 2007-10-11 at 13:10 -0400, Jeffrey Stedfast wrote:
> > On Thu, 2007-10-11 at 17:14 +0200, Philip Van Hoof wrote:
> > > On Thu, 2007-10-11 at 10:52 -0400, Jeffrey Stedfast wrote:
> > > > I have far better fixes in GMime that need to be ported to Camel.
> > > > 
> > > 
> > > Porting GMime to Camel would be an interesting effort indeed. Perhaps
> > > just replacing CamelMimePart with GMime.
> > 
> > Well... I hadn't exactly meant that it would be a good idea to
> > necessarily replace Camel's MIME parser/objects with GMime. I had simply
> > meant for Camel to lift GMime's rfc2047 decoder logic which does more
> > with charset fallback than Camel currently does... plus it also is a bit
> > more liberal in decoding malformed rfc2047 encoded-word tokens (well,
> > assuming ENABLE_RFC2047_WORKAROUNDS is defined...).
> Aha, so we can just look at what we find in the  #ifdef
> ENABLE_RFC2047_WORKAROUNDS #endif blocks and learn for your effort :)

well, you probably want all the code from those functions, even w/o the
#ifdef (that #ifdef really only works around the problem where
encoded-word tokens which are in the middle of other word tokens) in
order to get the charset fixes as well.

> Cool, thanks. (note. isn't spruce GPL and Camel LGPL?)

Well, GMime is separate from Spruce... but yea, I just realised GMime is
GPLv2+ - however, obviously I have an interest in improving Evolution
and so I give permission to Evo to use that code ;)

I need to poke the people who've contributed bits of code to GMime (the
code I mentioned in this thread was all implemented by me, so it's safe
to take) and make sure it's ok with them, but I'm likely going to
relicense GMime to be LGPLv2+


Evolution-hackers mailing list

Reply via email to