Re: [Nmh-workers] forw

[Ken Hornstein]

>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