Re: [Nmh-workers] Re: should nmh be an MTA or an MUA?

[Earl Hood]

On January 29, 2010 at 11:36, markus schnalke wrote:

> What exactly do you mean with ``users''? If you mean people that are
> no programmers, then I agree. If you mean us, then I don't.

I consider non-programmers.  If not, nmh will just be a nitch
MUA, and probably over time, die a slow death.

Not too many appreciate the power that nmh offers, but the command-line
(for whatever reasons) gets a bad rap.  Humans are visual creatues,
so GUIs have a natural allure, even if poorly written.

> Now I see why we do not understand each other:
> - For you, nmh is a system that provides everything for emailing.
> - For me it is an MUA.
> 
> >From your POV, nmh *should* include an MTA, a fetch program, and so
> forth. From my POV, it should *not*.

No, you project thoughts onto me to help support your argument.

I see nmh as an MUA.  Period.  See a separate post that quotes
RFC(s) on what the definition of a MUA is and what its role
is in the mail system:
<http://www.mhonarc.org/archive/html/nmh-workers/2010-01/msg00078.html>

I, and others, are only talking about the retrieval of mail
from an MTA and the submission of mail to a MSA or MTA.
Maybe you need to revisit the definitions and roles of the
various parts of the mail system.

Submission of mail is an MUA function.  If in the usage context of
nmh, the achieval of that submission happens to be achieved via some
third party program, it is STILL an MUA function, not an MTA function.

> I say: Write software for yourselfs, because otherwise you won't do
> it well anyway.

This statement seems to contradict the anti-NIH perspective.

> I want to motivate to forget the difference between library and
> program.
> 
> Separate instead of integrate.

I understand this, basic abstraction principles.  Where you
are off is what the functional role of an MUA is.  You are
attributing MUA-based functions as MTA functions.

> > Is the burden more on the the
> > application developer-side or the end-user side?  I tend to lean
> > toward the developer-side to make end-user life easier.
> 
> Good point. Thus, I much favor good end-user howtos (this is different
> to documentation). But I feel good design to be the higher goal.

Both are needed.  As of now, there is neither for some of things
that nmh users request.  And if there is information, it is scattered
somewhere on the Net instead of in the nmh documentation.

Does anyone still maintain the MH FAQ?

--ewh