Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!cbnewsc!gregg From: gregg@cbnewsc.ATT.COM (gregg.g.wonderly) Newsgroups: comp.mail.headers Subject: Re: MH verses the "all in one file" MUAs Message-ID: <1518@cbnewsc.ATT.COM> Date: 2 Jul 89 22:41:19 GMT References: <113461@sun.Eng.Sun.COM> Distribution: na Organization: AT&T Bell Laboratories Lines: 119 From article <113461@sun.Eng.Sun.COM>, by argv%eureka@Sun.COM (Dan Heller): > In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: >> >> And most of us use the appropriate MHL formats and filters to have them >> stripped later. Note that MHs repl(1) command (for replying to a message) >> will allow you to reply multiple times. The Replied headers are stripped >> from the resulting message by the time you see it in the editor to add >> your reply. > > No one said MH was stupid. There -are- other stupid UA's out there that > don't do the right thing (what you described is the right thing). But, > that has nothing to do at all with how a mail folder is stored. It is > incorrect to make the following statement: > >> people who continue to implement MUAs that use a single file for >> storing all messages seem to continue to replicate all the things that note that I said SEEM...^^^^ >> we hate about those programs. > > The reason this is incorrect is because your assumption is that it is > the single-file-folder "feature" that makes the program "bad." > A well written/designed UA should [try to] make it as transparent as > possible about the method for how mail is stored. You are making a > grave mistake by attributing the storage method utilized by a UA to the > bugs or implementation (design) features of that UA. If you think that > MH's "features" are a result of the fact that it's folder storage method > is attributed to the fact that it stored messages on a file-per-message > format, you are mistaken. I did not say anything about the merits of either method. What I said was that I have yet to see a "all messages in the same file" UA that does anything but what the others from the past do. People are spending a lot of time reproducing PD replacements for MUAs that don't do anything really that different and useful. > Believe it or not, I don't advocate using the folder-in-a-file method > any more than MH's method; there are good reasons for doing it both ways. > I hesitate to start yet another religious war about whether or not the > Mail-method or the MH-method is better, but I almost feel compelled to > do so anyway because of the misconceptions about UA's as described in > the previous text above. If the time has come yet again to resurrect > the war on MH vs. Mail folder formats, let's have it. I'm prepared. > I'm always looking for good suggestions for improving mush (oh, if I > only had the time), and in fact Bart and I have a long list of things > to do for the future if the future ever arrives. We're all working > together on this; I don't feel as if I'm competing with MH. 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)? By the time you have done that, what will have been added to MH that the other MUAs then won't have? I don't mean to start any wars on MUAs. I am just trying to see if the individuals doing the work are thinking about were they are going. It is a real waste of talent to continually play catchup, always adding the feature that you don't have yet. I had a personal reply from my original article that stated this >And MH is huge, and chews up disk space and inodes, and hard to learn, and >slow to use. There are several parts to this statement that should be thought about. MH is VERY large in source and executables. Mostly because it has a lot of duplicated code to provide the shell parameter parsing for each command, plus the copy of the libraries that rides with each executable (50 some odd executables exist). That, I cannot dispute. However, I take up the argument that this is not a problem, but rather a feature. If you have ever written an MH tool (I have written 4 to date), then you know how powerful and easy to use the library routines are. The INODE issue is a UN*X deficency, not am MH issue. Hard to learn is a perception, not a fact. Most people that I have introduced a tool to tell me it is easy when they have some experience with something similiar. MH is not like any other MUA that I am familiar with (I have exclusivly used MH for 5 years, so that leaves me mostly biased, although I have had the necessity to use others from time to time). However, much of MH's perceived difficulty is do to lack of coherent documentation. There are not any manual pages which provide a nice tutorial on where to start with MH, so the user is stuck with the command manual pages. Putting this aside, if you can type the strings inc scan unseen (or scan unread) show rmm refile you can use MH without any real difficulty. 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. Very few features of a program come free. There are design issues that can govern the relative order of complexity of an operation based on the underlying algorithym. I don't think that MH is perfect, there are a lont of linear algorithyms in it. The point is that certain things cost compute time. Some features of programs can be added in such a way that they always impact the application, even when the feature is not being used. The converse is also true (MH has such features like the 'previous' profile component). Give MH a try. If you hate it, throw it away (or even burn the tape in effigy). But at least try it. MUAs are really a religous issue, so I will not press any harder. I just needed to make some arguments against some of the bad things that people are saying about MH. ----- gregg.g.wonderly@att.com (AT&T bell laboratories) -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)