[Python-Dev] Completing the email6 API changes. (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Wed Sep 4 03:30:28 CEST 2013

R. David Murray writes:

I meant "a text/plain root part inside a multipart/alternative", which is what you said, I just didn't understand it at first :) Although I wonder how many GUI MUAs do the fallback to multipart/mixed with just a normal text/plain root part, too. I would expect a text-only MUA would, since it has no other way to display a multipart/related...but a graphical MUA might just assume that there will always be an html part in a multipart/related.

It's not really a problem with text vs. GUI, or an assumption of HMTL. There are plenty of formats that have such links, and some which don't have links, but rather assigned roles such as "Mac files" (with data fork and resource fork) and digital signatures (though that turned out to be worth designing a new multipart subtype).

The problem is that "multipart/related" says "pass all the part entities to the handler appropriate to the root part entity, which will process the links found in the root part entity". If you implement that in the natural way, you just pass the text/plain part to the text/plain handler, which won't find any links for the simple reason that it has no protocol for representing them.

This means that the kind of multipart/related handler I envision needs to implement linking itself, rather than delegate them to the root part handler. This requires checking the type of the root part:

# not intended to look like Email API
def handle_multipart_related (part_list, root_part):
    if root_part.content_type in ['text/plain']:
        # just display the parts in order
        handle_multipart_mixed (part_list)
    else:
        # cid -> entities in internal representation
        entity_map = extract_entity_map(part_list)
        root_part.content_type.handle(root_part, entity_map)

More information about the Python-Dev mailing list