After taking a closer look at the lob type I can not say for certain
that saving a Python string with an encoding will never come in to play.
As such I guess it is better to leave that feature in the lob type.
What we can do is move the code in mail.utils which handles the
boilerplate of working with unicode and binary data in lobs to the
Chandler utility package.
The textToUnicode method of the utility can be augmented to look at the
encoding and type returned by the lob and convert that to unicode.
This prevents developers from having to manually check the encoding and
type of the data in the lob.
For sharing however, since the framework must restore the lob in its
orginial form it would need to honor the encoding attribute of the lob.
Thus the sharing example I sent to you in a previous email of saving the
encoding would still apply.
Andi do you have any thoughts?
I can see a need for saving a string with an encoding but the majority
of textual use of the lob will be for assigning and working with a notes
body attribute which should 99% of the time either be binary or unicode.
--
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
