Ken Hornstein wrote:
I know it bugs you, and I understand why. But I doubt you'd notice, in
practice, on a modern system. Also ... you have 100 MB attachments?
But anyway ...
as i've explained to the KDE "KMail" team, assume 100 MByte attachments.
don't keep them in memory, and don't make copies unless you have to. MH
is generally smarter. for example, deleted files are just rename()'d. on
KMail, it's copied, in its entirety, to Trash, which means if you're on
low-BW WiFi, you spend 200MByte of WiFi dragging the message to your
laptop and then pushing it back to a different folder.
how hard would it be to just preserve the submessage structure and
attach it as an rfc822?
That's the thing that I don't think has been adequately captured ...
that's already been done! That's what forw -mime does! And maybe
I'm not understanding Norm, but I don't think he's really adequately
explained if or why that's not sufficient.
what those of us who loved and used burst(1) in the RFC 934 era, and i
may be speaking for Norm here but i don't know, is that "f" "o" "r" "w"
"\n" at the shell prompt just does the right thing. telling me that i
have to pay attention to how the message i received was encoded toward
me so that i can use the appropriate command line option to ensure that
it is forwarded in its entirety as it would have been in the RFC 934 era
sounds like crazy talk.
Well, specifically ... if you say "forw -mime 38 40", for example, you'll
get the following in the body of your draft:
#forw [forwarded message] +inbox 38 40
As long as you "mime" that message at the What Now? prompt, you'll get
exactly what you want; those two messages will be in the draft as two
message/rfc822 parts, complete MIME structure intact.
here's what i think you're forgetting. MH's user base is aging. we are
not attracting new 20-somethings. i am 53 now. old enough to learn new
tricks? maybe. i'm learning GoLang, for example. but am i going to
remember that "forw" works for RFC 934 format but that i have to invoke
it differently and also answer whatnow(1) differently if MIME is
involved? no. sorry, but no. brain cells die every day, and i have to
conserve the ones i have left for things which matter more to me than this.
i think what i'm suggesting is that forw needs a -auto option, which
ought to be made the default, which will detect that MIME was used
instead of RFC 934 on the message i'm forwarding, and DTRT ("do the
right thing") or perhaps even DWIM ("do what i mean").
(Currently if we get a message/rfc822 part, we don't descend into that,
but you can mhstore that message into a new message and work on it. That's
also something I want to fix).
as long as forw(1) picks up the message hierarchy in the forwarded
message, regardless of whether it's in RFC 934 or MIME format, then i
really don't mind if forw(1) lacks the ability to select specific
attachments and that i have to use mhstore(1) instead.
Now, if you're asking why that isn't the default .... sigh. By default,
unless you know to run "mime", that message won't do what you think. This
is the disconnect between MIME and draft composition; we don't have a good
way to tell the draft "incorporate this content". Although it occurs to
me instead of putting a mhbuild directive, we should create a new header
in the draft called "Forward" which contains the same information; this
would make more sense.
yes indeed.
--
P Vixie
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers