On Mar 24, 2011, at 03:54 PM, Glenn Linderman wrote: >When created by a parser, it could have the notion of size-seen-so-far, or >bytes-fed. Once the whole message has been processed, the size of the >message would be known, as well as of each piece.
It makes sense to record this in the Message objects, but I'd want to be very careful about what that attribute is called. Using just 'size' could be misleading, either because parsing has not completed, or because they might think that it's an exact count of the serialized size. Something like 'parsed_byte_count' might be okay though. >Incomplete messages, such as those from IMAP servers for which only partial >requests have been made for pieces, could only get the concept of "total >size" from the server, if it provides it. Since POP servers do, I think IMAP >would also, but I'm not an IMAP expert. In a case like that, an attribute such as 'server_reported_size' or some such would be okay. >For message parsing, it seems like allowing registered callbacks for various >pieces would be handy... "Call me when you parse this type of a header" (or >body part, etc.). I think David's design documents to allow for extensions and callbacks based on the content-types of things seen. Cheers, -Barry
signature.asc
Description: PGP signature
_______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com