Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!csd4.milw.wisc.edu!indri!caesar!blake!ogccse!schaefer From: schaefer@ogccse.ogc.edu (Barton E. Schaefer) Newsgroups: comp.mail.misc Subject: Re: MH verses the "all in one file" MUAs Message-ID: <3562@ogccse.ogc.edu> Date: 5 Jul 89 16:26:49 GMT References: <113461@sun.Eng.Sun.COM> <1518@cbnewsc.ATT.COM> <113567@sun.Eng.Sun.COM> <1526@cbnewsc.ATT.COM> <113637@sun.Eng.Sun.COM> Reply-To: schaefer@ogccse.UUCP (Barton E. Schaefer) Organization: Oregon Graduate Center, Beaverton, OR Lines: 162 Where have all the References: gone? Let's hope these attributions are correct ... In article <1518@cbnewsc.ATT.COM> (I think) gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: } Okay, here's some questions to think about. What does } mush/elm/mail/whatever not do that MH already does? How much effort will } it take to add those features (if they are desireable)? Aye, there's the rub. I've only used MH a little, but an (admittedly brief) perusal of the "Rand MH Message Handling System" document in the 4.3 BSD manual pages reveals that of the 6-8 things MH does that mush does not%, approximately 5 are things that mush intentionally avoids. ___________ % The counts vary depending on your definition. Mush handles *almost* all of the basic MH functions, and has hooks to attach most of the other functionality. Mush *could* handle virtually everything MH provides. It has the most trouble with "message sequences" and having them persist across exit/restart. ___________ } By the time } you have done that, what will have been added to MH that the other MUAs } then won't have? 50-60 separate executable programs, each with it's own UNIX-style man entry. :-) :-) (gregg.g.wonderly continues): } Now for the 'slow to use' part. The fact of the matter is that most people } using MH at universities are not going to have high speed CPUs. MH's } executables average about 200-300K here, and I imagine they are similar } in size elsewhere. This being the case, MH can be slow on a machine with } limited resources. But so is every other largish program I have seen. In article <113567@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) responds: } Mush averages about 100K and provides many features that MH has "as it } turns out." That is, I didn't design mush to be MH compatible, it just } so happened that some commands and features are very similar. With suntools, } the binary is bigger -- about 1 MEG or so depending on the version of sunview } or sunwindows you compile with. Without the curses interface, it's smaller. Just to keep Dan honest, Mush actually runs about 250K on BSD systems with the curses interface. MH's executables (on our Sequent) average just over 100K, ranging from a minimum of about 75K to a max of almost 300K. The difference here is not in the size of the executables but the number of them. There is a single mush. There are 30 executables in mh/bin and 11 more in mh/lib. (MH, like GNU, is not for small systems.) I don't know how the vmh and msh interfaces work, but if they fork/exec one or more of those 30 executables for every command, they've gotta have a lot more overhead than any single program. And even if vmh/msh avoid fork/exec, running all those individual programs from the [cbk?]sh, which seems to be the preferred way of using MH, does NOT avoid it. In article <1526@cbnewsc.ATT.COM> gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: } Several people make the statement that MH has some 'poor design schemes', } can you elaborate on those that you feel make it deficient? It's a matter of point of view. Obviously the designers of MH did not feel that their design was deficient, and you may not either. I have to admit that they followed admirably the "UNIX philosophy" of using a lot of small, specialized tools strung together to accomplish a larger task. The question is whether that is the best way to approach this particular problem. (No UNIX Philosophy wars, please.) MH is very flexible, and if you are a C or shell hacker you can probably make it do amazing things. There are a number of very impressive things (based on my quick look at the manual) that it% can do even without new programs hooked onto it. But how simply can the average person custom- ize MH to suit his personal preferences? And how many separate programs does he need to know how to configure to accomplish that? One last question about MH: How easy is it for Joe Random User to install MH in his own directory tree and use it in preference to whatever his system managers have decided is "best"? ____________ % Perhaps MH should actually be referred to in the plural, as "they". :-) ____________ (Dan, from back in <113567@sun.Eng.Sun.COM> again): } You have to start a new process (fork!?), set up pipes, parse command line } options, read init files (dot-files) and everything *for each MH command*. (gregg): } Yes, it does a lot of start up work, I don't know how one would get around } that, given MHs current design. I just don't like to here someone say that } a program is designed wrong because the features of the supporting OS make } it slow. This is a fact of life, but OS and HW designers need reasons to } start a new, and poor response from applications is a good motivation. Which came first, MH or UNIX? You can't blame UNIX for making MH slow. MH was designed to run under UNIX. If the designers of MH had felt that the speed of UNIX "features" was a problem, they could have designed around them. They chose not to -- which is fine, but you can't then turn around and say "UNIX did it!" when people complain. Now we return to the original Status: header discussion: In article wisner@mica.Berkeley.EDU (Bill Wisner) writes: } Clarification: } } The "normal" way for MH to display a message is just to print the whole } thing out, including all headers. This includes the MH-inserted Replied: } or Forwarded: headers. In <113637@sun.Eng.Sun.COM> island!argv@sun.com (Dan Heller) comes back: } Remember the reason this whole issue came up. Someone complained/asked } about the Status: header and Karl replied by saying that it's "bogus" } for the UA to add these headers to messages. Yet in reality, that is } exactly what MH is doing, so he defeats his own argument. A little referential confusion there. Bill defeats Karl's argument. Sort of. } Nevertheless, } I never agreed that this was a "bad thing." [Redundant French deleted.] } Not only do I see it as the only option (no other way to do it), I also } think it's a good thing to do. One would think that this puts the issue to rest. However, Dan then procedes to shoot himself in the foot (or at least the toes): } I will concede to the fact that MH's method of storing replied-to } information is better than Mush's. However, Mush will continue to } use the Status: header because this header is useful for other reasons. } For example, you can sort your mail by the status of a message (e.g. } place all replied to messages next to one another, group all new/unread } messages, saved messages, etc...). It takes vitually no user time at } all to do this because Mush doesn't have to scan message headers in order } to determine the status of the message -- when the folder is loaded, } the status is stored in internal data structures and retained as long } as the folder is open. Taking devil's advocate here, if the status is stored in internal data structures, what difference does it make whether there is a Status: in the folder? The internal status could be assembled based on any set of headers in the message. The question is, what is the real objection to Status: headers? Their mere presence, or that they store information in an encrypted form that is of little use without the help of the MUA in decrypting it? But returning now to the guts of the folder-format argument, Bill respnds to Dan's complaint about MH incompatibility with other MUAs: } Piffle. MH's packf command will take a bunch of messages and stick them } together into an MMDF mail file. You can use any other UA that understands } MMDF's file format. And speaking of religious wars, MMDF's format is } superior to the standard UNIX mail format. The "superior format" argument has gone off in another thread, but I wanted to make one comment. Providing a conversion utility is not the same thing as providing compatibility. MH doesn't care, because it is supposed to do everything (I believe "big stud mailer" was the term :-). -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer