Re: [Evolution-hackers] redesign of camel's mime-part content objects

[Jeffrey Stedfast <fejj ximian com>]

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  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com