>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
[email protected]
https://lists.nongnu.org/mailman/listinfo/nmh-workers
