[Python-Dev] Completing the email6 API changes.

[Stephen J. Turnbull]

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)