On Tue, 2003-07-15 at 23:28, Not Zed wrote: > On Tue, 2003-07-15 at 04:56, Jeffrey Stedfast wrote: > > On Thu, 2003-07-10 at 16:28, Jeffrey Stedfast wrote: > > > - CamelDataWrapper gets changed so that it has a CamelEncodingType > > > enum rather than int rawtext member (since rawtext will now always be > > > TRUE). > > Note that this will mean that camelmimepart has a duplicate of the > content_type and encoding parameters. > > Should: > - they be kept, and used as sort of 'intended' vs 'actual' values > - they be removed, since 'intended' vs 'actual' is already covered by > the fact you have a contentobject with its own values. > > > > - CamelDataWrapper::write_to_stream() will qp/base64 decode for us, > > > but will not do any charset conversion. Perhaps have a flag as to > > > whether to decode? this way if we are re-writing out the raw message > > > someplace, no need to have write_to_stream() decode, cuz then we'd > > > have to re-encode which would break the whole point of this change. > > > > > > Hmmm, could we maybe have camel-mime-part.c grab the dw's stream and > > > write that out raw instead? Will this work in the offline case? > > > Problem is that if we make the write_to_stream() interface take a > > > flag as to whether or not to decode, we have to pass extra garbage > > > (which wouldn't even make sense) when writing out CamelMimeMessages > > > or CamelMimePart objects. > > > > > > - camel-mime-part-utils.c will no longer qp/base64 decode the content, > > > rather it will just read it raw into a memory stream and then set > > > that on a CamelDataWrapper and also set which decoder to use. > > And on the inverse, when creating parts, we just attach them as binary > parts and set the content-transfer-encoding on the content object as > 'binary', but the mimepart's content-transfer-encoding to what we want > it set as. > > > hacked up most of the above, but it turns out I missed some things that > > are gonna be affected by this change. > > Sorry i didn't get back to you on all this earlier ... > > > 1. charset conversions in camel-mime-part.c:write_to_stream() - we can > > no longer depend on text parts to be in UTF-8 and stuff. This may not be > > so bad, however, since if the CamelContentType struct on the content > > data-wrapper should contain a charset param... we can then use that > > charset as the 'from_charset' argument and use the charset we want for > > output as the 'to_charset' like we currently do. > > Yeah this crossed my mind too. > > I think relying on the data-wrapper's content-type for the actual > content type of the physical content (as above) sounds good. > > > 2. the composer will have to set the content's charset to UTF-8 if we > > aren't gonna do the actual charset conversion there (we currently > > don't). > > Yeah this sounds good. > > And then we can set the charset we want to use to send it out with on > the container part?
yea, that's what I was thinking... > > > 3. camel-mime-message.c:camel_mime_message_set_best_encoding() will need > > to be fixed wrt charsets since it can no longer rely on the content > > being in UTF-8 > > It's really only needed when creating a new message whose content IS > already utf8, so it might not need to be changed much. ok > > > BTW as to your followup, should charset stuff just be removed - i would > tend to say not, because it'll be needed somewhere anyway, and it at > least centralises the code behind a simple api, rather than every user > of camel having to deal with the issue separately. ok. > > > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
