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
like
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. --
Nathaniel