[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] (no subject)

From: David Levine
Subject: Re: [Nmh-workers] (no subject)
Date: Wed, 20 Aug 2014 22:35:00 -0400

kre wrote:

>     Date:        Wed, 20 Aug 2014 09:46:18 -0400
>     From:        David Levine <address@hidden>
>     Message-ID:  <address@hidden>
>   | 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

>   | 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

>   | 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:


    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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]