How about some reports from the field about how different clients are
actually handling multipart/alternative. Does your client force you
to make an explicit choice about which alternative you want to see on
every multipart/alternative message you receive or do you configure it
once? Does it treat multipart/alternative as multipart/mixed? If the
message contains a nested hierarchy, are you forced to go through a
two-step interaction to see embedded elements?
OK, I'll bite. From a user perspective, my client (ML) acts pretty much
the same as the Frontier Technologies example. The part hierarchy is
"flattened" into a linear list but with indentation to display the hierarchy.
If the first "child" of the top-level multipart is text, it's presented. The
user has random access to any individual part without negotiating hierearchy.
(message/rfc822 is an exception because I display it recursively). I make no
distinction between multipart/mixed and multipart/foobar. They're just folders.
As you noted, this is an artifact of evolution. Future evolution will see some
parsing of the subtype, with special handling of parallel as the only thing
planned currently. These discussions might affect that evolution.
As a real world example, let's say I've got a mp/alternative with two
components, message/external-body and message/external-body, where the subtypes
are further broken down into access=mail-server and access=anon-ftp. (Look
familiar?) What is the "preferred" access method? I handle both of them. The
answer is "it depends". Sometimes I want the message directed at my mailbox so
it doesn't get lost in my filespace. Sometimes, I want the results _right now_
and don't want to wait for a mail responder. Throwing in an automated "decider"
is going to result in the wrong choice half the time.
Now let's say I've got another message, with text/plain and
app/postscript parts. The ps version is probably going to be prettier. So do I
make that choice automatically for somebody?
In this case my client defers the ps file to an external handler. That
handler might be a printer, it might be ghostview, and it might be decided at
invocation (yes, this is a choice too). You would think that ps would be the
preferred embodiment, but this might be a "sensitive" message, and if a printer
is the default destination, the person might not want it going there. OK, they
have a choice of outputs, no big deal. Oh, but ghostview isn't running on this
machine. It's either printer or save-to-file. What now? The user has to go
through a couple of steps to cancel the "external viewer" and also the
resulting "save-to-file" query. Maybe that's a bad design for me, but that's
how it is today. All they really wanted to do was have a quick look at the
message. THEY wanted the text part, and have to jump through hoops to get it.
Next example, same document. The text version is a few kbytes. The ps
version has graphics, is several megabytes, and we're connected over a slip
line from home. Here again, a printer default could be devastating if it's
directed at an office printer. But downloading the ps file to display locally
could take an hour or two. If we were at work, we'd want the ps version. At
home, it's out of the question.
All of this is a long way of justifying my current implementation,
which is to let the user decide which embodiment they want. But this is all a
design philosophy. Many designers regard users as incompetent to make choices,
and unable to handle complexity. In some markets that's the prudent design. But
it locks you out of markets where folks don't like to be spoon-fed. My audience
is generally a bit more sophisticated and I _try_ to let them make decisions
which I feel aren't absolutely clear cut. The challenge for me is to present
the choices in a meaningful way.
mike
PS> I *do* lock the compose window at 80 columns, and get a never ending string
of complaints from my "sophisticated audience" that it can't be resized. To me
it's not an option. It's the law. I guess this points out that no matter what
you do, you can't please everybody.