ietf-822
[Top] [All Lists]

Re: yet another way to indicate related MIME body parts

1993-10-27 06:30:34
Excerpts from mail: 26-Oct-93 RE: yet another way to indi.. Ned
Freed(_at_)INNOSOFT(_dot_)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.... 
 

<Prev in Thread] Current Thread [Next in Thread>