[Top][All Lists]

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

Re: [Nmh-workers] What are and what should be the qualifications for a c

From: Ken Hornstein
Subject: Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user
Date: Tue, 11 Nov 2014 18:49:33 -0500

>> I understand that some people find that useful, but I have not yet
>> been persuaded that it is nmh's job to provide an interface for
>> generic Unix text processing tools.
>That was there, whether by design or accident, from the start.  And I
>suspect it was clearly by design.  Regardless, it's part of the de facto
>contract with MH users.  I found that paper I was asking about, in nmh's
>git.  :-)  This is the one that started me using MH.
>    That is, the directory- and file-structure of UNIX is used directly.
>    As a result, any UNIX file-handling command can be applied to any
>    message.

I will note that is one paragraph, and the practical use of that feature
is not really mentioned (other than composition) in any of the original
MIME papers.  That's why I asked Norm about that; his answer was, basically,
"We didn't really think much about that part" (although I am sure Norm
will feel free to correct me if I am misrepresenting him).

As for the message store being part of the de facto MH contract ...
maybe, although perhaps we're arguing about the fine print.  Exactly
WHAT does that contract say?  If the contract says, "Hey, each file
contains a single, complete RFC-822 message", then we're meeting the
contract and no one has proposed to change it.

If the contract says, "All text content shall be accessable by traditional
Unix tools regarding of the MIME encoding" ... well, I'd be rather skeptical
of that, since MH predates MIME by a number of years.  None of the people
who added the rudimentary MIME support the MH (or nmh) felt like changing
the message store, although it's very probable that at least in the MH
days they did not envision the vast majority of messages NOT being
text/plain.  So I think MIME has blown up the fundamental underpinnings
of the original MH de facto user contract and I don't personally feel
bound by it anymore.  But I'd be willing to be persuaded otherwise!

>> Also, it's hard for me to get excited about writing a bunch of code
>> that will make nmh more complex for no gain to nmh.
>It seems we're struggling with how to handle MIME replies within the
>closed ecosystem of nmh.  Almost as if it were a monolithic MUA.

Well ... I take your point, but I don't think changing the message
store really would help for replies.  To me the issues there are:

- How do we "process" MIME parts of the replied-to message to generate
  the reply template?  This is sort of what I was talking about on the
  thread with David; how do we specify this in terms of UI, configuration
  files, etc etc?

- How do we then take these "processed" MIME parts and compose a MIME

The underlying store doesn't really matter, as I see it, for these two

>If composition took a similar directory hierarchy as the draft, that
>directory could be built-up piecemeal, partially with nmh's help, e.g.
>repl(1), but also with normal Unix commands for the more unusual uses.
>As needs become clearer through use, nmh can gain some of the more
>common operations itself.

Well, I could be persuaded that this makes sense for composition.  That's
an interesting idea ... you could build up a directory in the "right" format
and have it read by mhbuild.  What do other think of that?


reply via email to

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