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; 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 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
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 ... 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.
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".
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers