History may have been bad. However, it may teach very important
lessons. One should never ignore it, but one should go new ways if
appropriate.
Okay ... so, what, you're just dismissing my point here with some vague
"oh, all that stuff people did before, it might be wrong"?
And as for it being _easier_ ... well, literally, configuring the SMTP
MTS is as simple as placing this in your .mh_profile:
I personally, don't care much about easy, but I care about right.
(Especially, as this is what nmh does better as any other MUA.)
My response to this is twofold:
- "Right" is an extremely nebulous term, and you've basically proclaimed
that not having nmh submit messages via SMTP is "right", somehow,
without providing really any justification for this point ("Do one
thing and do it well" ... you could interpret that a hundred different ways).
- Nmh isn't just some exercise in architectural purity, right? We _want_
more people to use nmh, to contribute to it and expand it's use, right?
We don't want to make things _harder_ for users, do we?
Fetching mail is also the job of a different tool.
So, just so we're clear ... you want to remove the existing support for
POP in inc as well?
``Write programs to work together.''
Okay, nmh consists of many programs that work together, but nmh should
not strive to be self-contained. Don't let the NIH syndrome rule!
Nmh should work on a mailbox in the local filesystem. Incoming mail
should enter as plain-text through inc. Outgoing mail should leave as
plain-text to an MTA.
I understand the toolbox approach, but I don't actually see the problem
here.
In my mind, the power of nmh is that you have (relatively) simple,
individual shell commands that each perform a specific task, rather
than one monolithic interface. But the backend details of how they
perform those tasks? Not really that important to me.
"inc" brings messages from some external mail store into nmh. Sure, it
can work on a local file, and that might have been good enough ... 20
years ago. But nowadays the standard has moved toward retrieving your
messages via POP or IMAP. Sure, you _could_ have some external tool
perform this mail retrieval operation ... but really, what are you
gaining here? Clearly the original designers of MH didn't see any
reason to force the use of an external tool ... they saw no problem
with POP support in inc. The idea that somehow POP support in inc
violates some basic MH design philosophy is completely ridiculous.
Correspondingly, "send" is the tool that pushes messages out to the
Internet at large. The details of how it does this? Again, not so
important to me. You can feed messages to some tool that does it for
you, or submit your messages to a qualified MTA via SMTP. And once
again, the original designers of MH didn't see a problem with it.
I fail to see how these features really violate the sentences you
give as examples.
``Write programs to handle text streams, because that is a
universal interface.''
(I admit, this does not exactly match the point.)
That's a great theory ... but I fail to see how it's really relevant.
At some point, _some program somewhere_ has to talk over the network
to get and retrieve email. You argue about generality ... but that
has it's own issues it introduces (providing an in-place implementation
lets us give more timely and appropriate error messages to the user,
for one).
We could avoid the SMTP protocol implementation, and thus a lot of
complexity, by simply piping to a command.
You know, I'm going to repeat this again, because somehow you've missed
this point: nmh does not include a complete SMTP protocol implementation.
The code in nmh is a submission client only. In terms of protocol
standpoint, it's very simple, because it doesn't need to be
complicated.
I know the reasons why it is like it is. I know, that some things look
easy in the beginning. But in the end, what matters are simplicity,
clarity, and generality.
But not usability?
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers