kre wrote:
Date: Wed, 20 Aug 2014 09:46:18 -0400
From: David Levine <levinedl(_at_)acm(_dot_)org>
Message-ID:
<15304-1408542378(_dot_)667983(_at_)nZLB(_dot_)VY7x(_dot_)FQve>
| 1) I use "preferred" the same way that RFC 2046 §5.1.4 uses it:
OK, but that's (as you said) from the sender's perspective. When I am
using these tools, I'm not the server, and it is my preference that should
matter.
That's fine. But these tools MUST support my preference, which is to
display the most preferred, as determined by the sender, alternative
that I can display. mhshow does. mhlist's output agrees with it, as
I tried to explain to Ken here:
# Now that you bring up multipart/mixed: mhshow and mhlist
# display and list, respectively, the parts of multipart/mixed in
# the same order. mhshow and mhlist also (attempt to) display and
# list, respectively, the parts of multipart/alternative in the
# same order. This is just another way of looking at why I think
# it would be wrong to change mhlist. We'd have inconsistent
# behavior.
| Boundaries are at a low level, MIME structure is at a higher level.
The boundaries define the MIME structure (along with the associated
headers) so they're really at the same level - forming the content
of them might be a lower level but that's not relevant here.
I disagree, and it is relevant. It's easy to show that boundaries
are at a lower level: other mechanisms could have been used to
delineate message parts while supporting what we now recognize as
MIME structure. The user of tools for doing expected manipulations
with the message wouldn't know, and shouldn't care, about that
mechanism.
| mhlist doesn't present the boundaries, even with -verbose.
No, but it uses them.
Of course, but just internally. There's no need for it to present
them.
| And, my whole point: because scripts rely on MH/nmh commands,
| don't change those commands (when not necessary).
I agree with that principle, but here it really is necessary - the
current behaviour can't really be justified as anything other than a bug.
That it was recently documented doesn't change that characterisation.
I haven't seen any justification for calling it a bug. All I've
seen is that it's a preference. It is not necessary to impose a new
preference for display order on owners of existing scripts.
I just found that it's documented in Jerry's book:
http://oreilly.com/openbook/mh/limimepa.htm
Last change $Date: 1996/06/06 15:11:06 $
| If mhlist ordered multipart/alternative parts in increasing
| order of preference, I'd have to iterate from the back.
You could, but I wouldn't - better to simply iterate over all the
alternatives, and remember which one is the one you want to display.
That's fine. But also not as simple as search until you find one
you can use.
looking at all the alternatives makes it easy to allow the user to
set their own preference to override the sender's (which seems to be
a much requested feature - hard to implement at the minute (I
assume) because the code is not looking at all the alternatives).
mhlist does display all of the alternatives and mhstore can store
any of them, and mhshow can display any of them. Any user
preference is currently supported, using -part or -type.
All we're talking about is the order of display of alternatives of a
multipart/alternative by mhlist (with consistent use by mhstore).
| mhlist does show what is actually in the message. Nothing is
| lost with the presentation.
No it doesn't, for a message I have ...
msg part type/subtype size description
47 multipart/alternative 27K
1 text/html 10K Message in HTML form
2 text/plain 9984 Message in clear text
but when I look inside the message, the first alternative is
text/plain and the second is text/html - mhlist is lying to me.
mhlist isn't lying. You define the order of alternatives
differently than it does. You don't have to like it, but it's not
lying.
If I were to write a script (not using mhstore, but sed) to save
the text/plain part, I'd get the html variant instead. That's
just broken.
The sed script would be broken, not mhlist. No doubt we disagree
on that, but you and Ken haven't been able to convince me otherwise.
When I asked: "Is there anything *wrong* with the current behavior?"
Ken's response was about preference. Our preferences our different,
but neither is wrong. Therefore, I see no reason to change a 22-year,
at least, precedent.
If you guys want to add an "-alternatives best-first" switch, or
maybe better, some profile component to display in that order, have
at it. Just don't change the default behavior.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers