[Email-SIG] fixing the current email module

[Barry Warsaw]

On Oct 6, 2009, at 8:30 PM, Stephen J. Turnbull wrote:

> What that means is unclear, though.  Does a "header in wire format"
> mean before or after MIME encoding?  Probably after, but that's pretty
> useless for the purpose of editing the header.  Does it include the
> tag (the part before the colon) or not?  Etc.

This is a great question.  As far as headers go, sometimes you want to  
reason about the entire header (field name + value) and sometimes you  
just care about one or the other.  Putting the field name in the  
Header instance means it's difficult to copy the header to other  
fields.  Not having the field name in the instance means that some  
calculations (such as line length) are tricker.

> That depends.  For example, multimedia parts may simply be discarded,
> in which case it makes sense to not convert them.  However, most
> Mailman lists do add a footer, and because of crappy Windows MUAs that
> don't implement MIME correctly, it's preferred to add that by
> concatenating as text.  That simply cannot be done correctly in wire
> format for any character set except ISO 8859/1.

Even then, doesn't it depend on the character set of the text you're  
appending too?  Aren't there for example some Japanese character sets  
that are incompatible with iso-8859-1?  Mailman punts and says if the  
character sets aren't identical, it cannot concatenate.

>> Heading and footing texts are configured boilerplate, and could be
>> cached in a variety of formats to avoid the need to convert them for
>> each message,
>
> Premature optimization is the root of all error.

I could not agree more.  Plus, according to Moore's law, computers  
will all be 256 times faster when we finish the email package redesign  
than when we started it <wink>.

>> An archiver could archive wire format,
>
> Are you suggesting that the email module should mandate that?  We have
> a severe tail-dog inversion problem here.

Right.  Remember that the email package is fundamental to all of this,  
so it must provide the services that client applications need.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/email-sig/attachments/20091007/bb3a90ba/attachment.pgp>