[2010-01-28 10:39] Ken Hornstein <kenh(_at_)pobox(_dot_)com>
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).
Interpret it as it is done by the tools of the Unix toolchest. (Not
the GNU utils but the ones from Bell Labs.) You know ``cat -v
considered harmful'' [0] ?
[0] http://harmful.cat-v.org/cat-v/
If not, read it!
My ``right'' is what (I think) the Unix Philosophy tells.
- 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?
I agree that making it harder for users to switch to nmh is bad.
But why should a users switch to nmh if he wants it just to be easy?
He'd take some monolithic MUA instead.
Nmh enables users to do some things better than possible with other
MUAs. This mostly results from nmh's one-tool-for-one-job approach. I
think there are places where we can go one step further. Then we might
gain possiblities we do not think of yet.
Have you read ``The Cathedral and the Bazaar''? Especially the part
when esr realized he could make it simpler by speaking only one
protocol, is interesting [1].
[1] http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html
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?
I think it would be better to not have it, yes.
BUT:
This is what I personally think about it. I *really* don't plan to
change all that stuff in an gsoc project.
It's much more your software than mine (no matter that it's free). I
know that you are miles ahead of me. I will *not* tell you what you
have to do.
What I try, however, is to show you a point of view, you might not
have taken. It may seem extreme, but Unix itself is extreme. In the
end, most stuff I tell you bases on what I read in books like:
- Ganzarz: ``The Unix Philosophy''
- Brooks: ``The Mythical Man-Month''
- Kernighkan & Pike: ``The Unix Programming Environment''
- Kernighkan & Pike: ``The Practice of Programming''
and similar literature
These are not my ideas, these are the ideas of very clever people.
``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.
From the user's POV, I agree that nmh is very nice. But conceptionally
it could be improved, I think.
You might say, that ftp is nicely handled under Unix. I would have
agreed, just a few years ago. But when you met Plan9 and see how they
simply mount the external storage, via an ftp layer, into the
filesystem, then you can never want the ftp command back.
"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.
It violates the Unix Philosophy: Do one thing, and do it well!
Inc might do the POP stuff not badly, but it would be better done it a
tool which does only POP retrieval. If you can concentrate on one
thing, you will do it better, than if you concentrate on two things.
You say, emailing has changed through the years. Thus inc needed to be
improved to to authentication or whatever. Send needed also to be
improved. If these improvements would not have been done, then nmh
would be usable anymore.
But if nmh (that means MH) would have always communicated to the
outside world by receiving plain text through inc and sending plain
text to an external command, then some changes in the email world
would not have affected nmh at all.
If in five years, there is a new protocol that everybody uses, then
you have to implement support for it in nmh. But mail retrieving
software and MTAs will implement such support for sure, because this
is their main job. I'd say it is better to take one of these tools
then and don't need to care about the new protocol.
If it is better in the future, then we should start now.
I fail to see how these features really violate the sentences you
give as examples.
If you see why `cat -v' is bad, then you will see my point. If you do
not, then you probably will not get my point.
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 admit, that I like to take extreme points of view to show something.
The world is mostly a compromise. There are always pros and cons. You
might be right at this point, you might be at others. At least you
have deeper knowledge and more experience.
But nobody in the 60s thought, that an operating system with the
simplicity of Unix would be possible, until some guys showed, that it
was. Today, you all like Unix for what it is. (Remind: I almost only
tell you ideas of those guys who invented Unix.)
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?
Usability does lead to bloated monolithic software. Look at most of
the software we have today.
meillo
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers