I'm going to go out on a limb here (start sawing!!) and claim that
multipart/parallel was put in to the spec because somebody wanted the cute
effect of seeing a picture and having the audio play at the same time
(parallel
presentation). This is known as poor-man's synchronization.
This coincides exactly with my recollection.
It has about zero worth - anybody really doing presentation-style stuff needs
much more sophisticated synchronization mechanisms.
This is much too strong. multipart/parallel can be made to work very nicely and
is more than sufficient for many applications. Yes, the synchronization model
is very primitive. Yes, you can do much neater things with a more powerful
model.
I do a fair amount of sound design; as a result I own several pieces of
studio-quality audio gear. And I, like many others, tend to sneer at the
fidelity offered by clock-radios, cheap stereos, and so forth. But I when I
need to wake up at a particular time guess what I use... a clock-radio. I
suppose I could hook up my 4-track 15IPS tape deck to my 32 channel sequencing
time controller, but it sounds like a lot of work just to get muzak played in
my ear in the morning.
A tool either has uses or it doesn't. Expecting multipart/parallel to replace a
comprehensive compound document scheme is just plain silly. But expecting
everyone who wants to send a cartoon with a voice-over and doesn't want to
spend more than 10 seconds sending the message to use a large and powerful
document editing package is equally silly.
Don't expect multipart/parallel to steal any thunder from compound document
systems. This does not change the fact that multipart/parallel fits in a useful
niche at present.
The claim that /mixed and /parallel are effectively "ordered" and "unordered"
collections is a post-facto interpretation. Frankly, I don't see the worth
of the distinction for MIME, but I'm certainly aware I could be missing a key
use (but as Neil has said, better to make this explicit or people will use
the mechanism for different and possibly incompatible uses).
It is definitely a post-facto interpretation. It is also incompatible with the
original intent, and as I have previously stated I don't think the language in
the RFC is unclear on this. You have to really twist the words in there to
wedge in these new interpretations.
On the attachment issue, I think it is clearly a presentation hint on an
object
by object basis. The approach of using a multipart subtype is basically
saying
- we need to attach additional information to this object, so we'll place some
structure around it and add a label to that structure. I think this is
wrong-headed, because you're really not specifying structure. An additional
Content-* header seems like the simplest way to go and the most direct.
Thank you very much for saying this! You did a much better job of it than I
have been able to do. I agree completely with all of this.
Am I wrong, or is the critical distinction between an attachment and an
embedded object simply how it is presented to the user? Who says all
attachments have to go at the end of the document?
I certainly don't!!!
In Slate, I would presume
that if someone indicates something is an attachment, I'd represent it in a
small iconic form (but it would show up whereever they had put it in the
document).
I tend to think of this in terms of the "click to present" model. An attachment
would default to popping up the "extract to file" menu while a simple part
would default to invoking whatever viewer/player/editor is appropriate to
actually see the contents.
The line between these gets a bit fuzzy when you get into things like
Nathaniel's metamail stuff, which uses a mailcap file to invoke the appropriate
viewing application for a given type. I would model attachment information by
making it additional input data to this file, so that (for example) a
PostScript part would bring up the PostScript viewer while a PostScript
attachment would bring up the "save to file or print" widget.
The additional structure information would be useless to me.
(The parallel information is also useless - I treat parallel the same as
mixed).
I would try to treat multipart/parallel as truly simultaneous; I would bring up
whatever viewers and players were appropriate. Yes, if you have two
simultaneous audio tracks they won't get played right without a lot of
implementation tweaking. Lots of color pictures look like garbage on my
greyscale monitor, but this isn't a reason to ban sending color pictures
around.
As for gateways, if a gateway knows that it is heading into an environment that
doesn't support a parallel viewing paradigm but does support a compound
document format, the solution of choice would be to convert the parallel
structure into a compound document. This requires a lot of knowledge about the
environment, but this knowledge is embodied in the gateways if it is anywhere.
Finally, the other direction, where a compound document gets converted into a
multipart/parallel structure, is one I have profound misgivings about. Part of
this is just my natural dislike of information loss. On the operational side,
the environment I use has a very powerful and complete compound document
definition associated with it, and I have lots of tools available to manipulate
this stuff. Moreover, some knowledge of this is built into the operating system
itself, so that when an application in need of a text file gets ahold of a
compound document it sees ... a text file. This is a very cute idea, but it can
be very confusing, when, for instance, I happen to type out a compound document
containing only images and I get no output. This is a mixed blessing at best,
and I think users will have to become a lot more familiar with this sort of
thing before tricks like this will be anything other than confusing.
Ned