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

[markus schnalke]

[2010-01-28 10:53] Earl Hood <address@hidden>
> 
> At some point, nmh must be able to read (incorporate) mail to
> do its job.  I.e.  It must "fetch" the mail from something, somehow.
> 
> At the time MH was written, local spool files was all there is, but
> things change.  POP came to be a legitimate (standard) delivery model,
> so MH was adopted to support it.  From my understanding of the history
> of MH development, the intent was to have it be in-sync with Internet
> mail standards.  Remember, MH, early on, provided MIME support before
> most MUAs did, and while attended UCI years ago, there was still some
> active development with MH promoting this perspective.
> 
> Nmh should try to stay in-sync with Internet mail standards,

This needs steady development of nmh in all involved fields (also
mail retrieval and transfer). By using external tools, only the core
job of nmh (= reading, organizing, and composing mail) needs to stay
in sync. Everything else will be in sync ``automatically''. (I know
``automatically'' is an illusion.)

> not
> relying on external tools to support features MUAs are expected to
> support directly.

``are expected'' is the end in such discussions: Doesn't the world
expect MUAs to be monolithic? Doesn't the world expect web browsers
to be monolithic? (See uzbl.org)

Beware of the NIH syndrome. Unix is so good, because it *does* rely
on external software. That's what ``software leverage'' means.


> I think mail retrieval and submission are core
> MUA functions,

We are in total contrast in this point.

> and an MUA should support the standard mechanisms for
> doing so.

It should support the standard mechanisms for its core tasks, yes.
But it should not include lots of stuff that is externally available.
You do use external libraries, why not use external programs?


meillo