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

[Jeffrey Stedfast <fejj ximian com>]

- CamelDataWrapper gets changed so that it has a CamelEncodingType
  enum rather than int rawtext member (since rawtext will now always be
  TRUE).

- 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.

- this means the mailer code will have to do its own UTF-8 conversion,
  but that isn't so bad - most of the code is already there to do that
  anyway.

  - need to scan the text stream if it is an iso-8859-x charset in
    order to check for it being a windows-cp125x charset (should we do
    this even in the case of a user specifying the preferred charset
    to display as? probably not).

  - parse the HTML to get the HTML content charset in the case where a
    charset isn't specified in the Content-Type header?

- camel-mime-part.c:write_to_stream() will get simplified a bit by not
  needing to worry about base64/qp/etc encoding because the content
  will already be encoded.

  Actually, no, we'll still have to worry about this because we may
  have to change the content-transfer-encoding when sending mail or
  something. The way I handled this in gmime was to check if the
  encodings were the same on the dw and the part, if so - just write
  the raw stream (dw->stream), otherwise use the dw's
  write_to_stream() method to write the decoded stream to a filtered
  stream that would re-encode it in the proper encoding.

  if we do it this way, then we shouldn't need to worry about changing
  the way the composer code works (which is a plus).

- anything else? other than renaming CamelDataWrapper::offline to
  something more intuitive, like maybe 'is_remote' or 'offsite' or
  something.


-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com