Ken Hornstein wrote:
MIME broke all that. a lot of UI's can't cope with attachment trees
where one rfc822 includes another which has attachments. the way modern
graphical MIME UI's work is by iterating down through the forwarded
message's MIME tree and attaching each attachment to the top level of
the forwarding message. this is quite destructive, and complicated, and
expensive. but it's what forw(1) would have to do.
Well, I don't know if I would say it would be destructive or
complicated;
it's destructive in the sense that it flattens the original structure
which may have had meaning. if four people edited a document in a back
and forth fashion and kept sending the latest version, i'd like to be
able associate the version they sent with the e-mail that attached it.
especially if their file names did not change, or were changed in some
incomprehensible way.
it's complicated in that RFC 934 was about as simple as cat(1).
in THEORY any reasonable MIME parser should be able to
handle it. Expensive .... maybe; I don't think it would be bad on a
modern computer.
if it's a 100MByte attachment then i rather hate having to make a copy
in my local file system of each (or perhaps, all) attachments as i go
about destructively flattening things. far better to just include the
enclosing message as an rfc822 attachment and let the receiver see the
depth and avoid an extra copy in and an extra copy out of /var/tmp.
If we get "full MIME parsing" (see previous email)
forw could do something like:
for each msg in msg-set:
for each mpart in msg where disposition == attachment
add mpart to draft
end
end
yes and if wishes were horses we all could ride :-).
If you write a set of MIME parsing libraries, retool the entire nmh API,
solve all of the encoding issues, define a syntax for MIME parts, define
an ATTACHMENT syntax for MIME parts ...
that's a god damned lot of god damned work, for those watching from the
sidelines.
the code in forw is relatively
straightforward and simple. It's just doing all of THAT is a huge pile
of work. It's work I would like to tackle ... but you know, I have
a job, a family, and all that.
sing it, brother.
Like I said, I understand why people would WANT this to happen, but when
it comes to MIME if you're asking the question "Why does nmh not do<X>?"
the answer is almost always, "Because nobody wrote that code".
how hard would it be to just preserve the submessage structure and
attach it as an rfc822?
--
P Vixie
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers