On Sep 16, 2010, at 11:45 PM, Terry Reedy wrote: >Based on the discussion so far, I think you should go ahead and >implement the API agreed on by the mail sig both because is *has* been >agreed on (and thinking about the wsgi discussion, that seems to be a >major achievement) and because it seems sensible to me also, as far as >I understand it. The proof of the API will be in the testing. As long >as you *think* it covers all intended use cases, I am not sure that >abstract discussion can go much further.
+1 >I do have a thought about space and duplication. For normal messages, >it is not an issue. For megabyte (or in the future, gigabyte?) >attachments, it is. So if possible, there should only be one extracted >blob for both bytes and string versions of parsed messages. Or even >make the extraction from the raw stream lazy, when specifically >requested. This has been discussed in the email-sig. Many people have asked for an API where message payloads can be stored on-disk instead of in-memory. Headers, I don't think will every practically be so big as to not be storable in-memory. But if your message has a huge mp3, the parser should have the option to leave the bytes of that payload in a disk cache and transparently load it when necessary. I think we should keep that in mind, but it's way down on the list of "gotta haves" for email6. -Barry
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
