[2010-01-28 10:53] Earl Hood <earl(_at_)earlhood(_dot_)com>
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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers