On Oct 9, 2009, at 2:59 PM, Glenn Linderman wrote:
It would be good though to have standardized terms for easier communication. Maybe as they are chosen, they could be added to that Wiki RDM set up?
I like raw, transfer-decoded, decoded (or maybe fully-decoded). As I've mentioned before, I don't think the Message or Header APIs need to directly support transfer-decoded.
Separate APIs would be clearer, but for compatibility, should .get_payload() be retained, with the flag?
No. It was a mistake that should be taken out back and shot.I would proposal a radical suggestion: we treat backward compatibility the way Python 3 did. Nice to keep, but we can throw it over the side in order to fix the warts. We'll worry about migration strategy later.
Aside: I would really like to have a much more @property based API where appropriate. E.g. Message.get_content_type() would be Message.content_type. And in this case we'd probably have message.payload_bytes or some such. Decoding may require additional parameters so it will probably be a method.
Sure, a registration system is fine. It could work for any type that has a method that can be registered, that accepts a binary BLOB and returns an appropriate typed and functioning object that can manipulate that type. That would mean that the application would have to make all the registration calls up front, instead of making the API calls when the objects are retrieved. Basically, if the email package doesn't have a registration system that the application can use, the application has to invent its own, so this is work that could benefit all applications.
I'm sure there will be lots of default content-types registered, and there ought to be a "default" or fallback converter that can be overridden. It should also be possible for third party extensions to add additional converters. Models for this would be timzeone additions for datetime, and codecs.
Actually, although it is not common practice to have encodings other than the RFC defined base64 and quoted-printable, a registration system for converting from #1 to #3, with appropriate defaults for base64, quoted-printable, binary, 7bit, 8bit, would be appropriate,
That makes sense. -Barry
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
