[2010-01-28 10:39] Ken Hornstein <k...@pobox.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@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers