[Top] [All Lists]

Re: yet another way to indicate related MIME body parts

1993-10-26 07:52:54
Excerpts from mail: 25-Oct-93 Re: yet another way to indi.. Keith
Moore(_at_)cs(_dot_)utk(_dot_)edu (3620) 

I'm concerned about that too.  There are ways around this, but they're not 
simple.  As long as there's a copy of the whole message on random-access 
storage, the called programs can access that.  The calling mail reader could 
keep track of the start position and length of each component's header and 
body, and write *those* to a file, but then the called program would have to 
do its own decoding. 

Ugly.  The nice thing about separate files in unencoded form is that
non-MIME aware apps can often work well with them. 

(How many of the programs in the average mailcap file *already* require the 
body part to be stuffed in its own file?) 

Not all of them, by any means, and those that can take their data via
stdin get big efficiency gains, on UNIX at least. 

Basically I figure that if we're going to let body parts reference one 
another, we have to pay the extra overhead.  It's similar to what you pay to 
get multipart/parallel.  (But is it worth the extra overhead to do things 
appledouble, file transfer, delivery reports?) 

Yes, actually it probably is worth it.  The question is still whether
the general mechanism adds anything to what you can implement by
subtypes such as multipart/appledouble or multipart/enabled-mail.  --

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