Re: yet another way to indicate related MIME body parts

[Nathaniel Borenstein <nsb@xxxxxxxxxxxxxxxxxxxx>]

Excerpts from mail: 26-Oct-93 RE: yet another way to indi.. Ned
Freed@INNOSOFT.COM (4854*) 

> > In a metamail-like environment, it appears that multipart/foo puts a big 
> > burden on the programs that must interpret such body parts, because
> they have 
> > to be able to parse multipart MIME messages. 

> I disagree. multipart/foo is either recognized, in which case it is handled by 
> an appropriate handler that knows what to do, or it isn't, in which case it is 
> treated as multipart/mixed. In either case the decision is easily made
> based on 
> the existing mailcap facility. The appropriate handler can easily do whatever 
> it needs to do to the inner parts. 

Actually, the situation is much BETTER than even Ned implies.   Recent
versions of metamail have added support to make it much easier for
people to write new multipart subtype handlers.  In particular, in a
mailcap entry for a multipart/foo handler, %n will be replaced by the
number of parts within the multipart object.  %F will be replaced by a
series of arguments, two for each part, giving first the content-type
and then the name of the temporary file where the decoded part has been
stored.  In addition, for each file created by %F, a second file is
created, with the same name followed by "H", which contains the header
information for that body part.  Of course, metamail handles the temp
file cleanup after the handler exits.  All of this means that, for any
value of "foo", you can easily write a multipart/foo handler for
metamail without understanding ANY of the details of transfer-encoding
or MIME multipart structure!  So I think Keith's "burden" is illusory. 

> So now let's crank through the code and add another squirrel 
> file (maybe we'll call this one a rabbit file, for variety) to handle this 
> special case. Yuck! 

Sigh.  The early versions of metamail were probably the cleanest code I
ever wrote, because I suspected it would be widely read, and that any
ugliness in the code would embarass me for a long time.  I was right.  I
should never have tried to implement multipart/alternative in the main
program.  Now I'm going to hate rodents for the rest of my life....