[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] forw

From: Ken Hornstein
Subject: Re: [Nmh-workers] forw
Date: Sun, 09 Oct 2016 22:36:50 -0400

>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

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".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]