[2010-01-28 10:53] Earl Hood <[email protected]> > > 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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
