gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (07/01/89)
From article <WISNER.89Jun28221923@anableps.berkeley.edu>, by wisner@mica.Berkeley.EDU (Bill Wisner): > MH can be instructed to keep track of messages that have not been seen by > putting them into an "unseen" sequence. It never touches the actual messages > to do this. > > ... > > Note that MH does none of these things unless explicitly told to. 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. Just a note... It has been said many times before... Those who ignore the past are doomed to repeat it in the future. In other words, those people who continue to implement MUAs that use a single file for storing all messages seem to continue to replicate all the things that we hate about those programs. MH is so elegant and flexible. It pains me to see all the work people are doing just to duplicate what has already been done. ----- gregg.g.wonderly@att.com (AT&T bell laboratories) -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)
argv%eureka@Sun.COM (Dan Heller) (07/01/89)
In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > From article by wisner@mica.Berkeley.EDU (Bill Wisner): > > MH can be instructed to keep track of messages that have not been seen by > > putting them into an "unseen" sequence. It never touches the actual messages > > to do this. > > Note that MH does none of these things unless explicitly told to. > > 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 > 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. 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. > gregg.g.wonderly@att.com (AT&T bell laboratories) dan <island!argv@cad.berkeley.edu>
argv%eureka@Sun.COM (Dan Heller) (07/01/89)
I meant to proofread this, but apparently, I missed something... > 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 meant to say : If you think that MH's great features is attributable to its method for folder storage, you are mistaken. My intent was to point out the fact that a good UA should do the "right thing" regardless of how that UA stores its messages. Two "correct" UAs --each which stores files using the Mail and the MH method-- should do the same thing when it comes to replies, etc... dan <island!argv@cad.berkeley.edu>
gregg@cbnewsc.ATT.COM (gregg.g.wonderly) (07/03/89)
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)
ut6y@vax5.CIT.CORNELL.EDU (07/04/89)
My $.02 cents... The main thing I find ELM (for example) has over MH, both of which I have, in my time, installed and used extensively, is speed. Elm2.2 is considerably faster on our little Vax 750 (Vax1.cit.cornell.edu) than MH6.6. Both, I find, provide a great number of features that I like, and in general, balance out in every other way. The other advantage to ELM is that you don't have to go through EMACS to get a really good screen interface. The final advantage is simply that it is compatible with normal Berkley Mail. This may not seem important until you realize that there are times when one has to, for whatever reason, resort to old Mail/Mailx. MHMail requires a format conversion in order to integrate whatever you did under Mail. Elm does not. Unc .
wisner@mica.Berkeley.EDU (Bill Wisner) (07/04/89)
In article <18916@vax5.CIT.CORNELL.EDU> ut6y@vax5.CIT.CORNELL.EDU writes: >This may not seem important until you realize that there are times when one >has to, for whatever reason, resort to old Mail/Mailx. HAH! Bill Wisner wisner@mica.berkeley.edu ucbvax!mica!wisner I'm not the NRA either.
njs@scifi.UUCP (Nicholas J. Simicich) (07/09/89)
In article <18916@vax5.CIT.CORNELL.EDU> ut6y@vax5.cit.cornell.edu (The Dread Pirate Mikey (Mike Shappe)) writes: >The final advantage is simply that it is compatible with normal Berkley Mail. >This may not seem important until you realize that there are times when one >has to, for whatever reason, resort to old Mail/Mailx. I think that I can say that this isn't true in my case. And I know many other people who do all of their mailing on Unix (AIX) who use mh-mode in GNUemacs, rmail mode in GNUemacs, or XMH, and who never use the Berkley mail command. Me? I like RMAIL mode.... -- Nick Simicich --- uunet!bywater!scifi!njs --- njs@ibm.com (Internet)
argv%eureka@Sun.COM (Dan Heller) (08/08/89)
I am moving this discussion to comp.mail.misc because it doesn't have anything to do with headers anymore. The reason this all started was that someone took notice of the Status: header present in Mail-based MUA's. Mail, Elm (I guess), Mush, mailx, ... all do this: use the Status: header to save information about whether the message is new, unread.. Mush also uses the status header to store info about whether the message has been saved, replied to, and so on. Greg points out that MH saves this info as well, but not in a header which is visible to the user -- MH apparently filters this information out when the message is displayed. The first part of this message contains the preliminary discussion between us. The latter part of the message actually discusses the drawbacks of MH and a few comments about Mush. People who are interested in continuing a discussion about good MUA development as well as hardline MH users are encouraged to read this message and participate in the discussion. Sorry if the preliminary dialog is hard to follow -- I edited it to make it clear about the direction the discussion is going. In article gregg@cbnewsc.ATT.COM (gregg.g.wonderly) writes: > 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. > > > > There -are- other stupid UA's out there that > > don't do the right thing [referencing how mail is replied to]. 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...^^^^ Yes, you said "seem", but the implication is clear :-). Nevertheless, I'm willing to let it go. > > The reason [your statement] 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. You later admit that you haven't used anything else but MH for the past 5 years, so this statement doesn't carry much weight. Nevertheless, your observation is somewhat accurate: Most UAs developed today are limited in either functionality (feature-list) or tend to be ill-designed and are desitined to make the same mistakes as those that preceded them. With these problems in mind, I designed Mush for the purpose of avoiding these problems while taking advantage of other issues (described later). > 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 want to discuss the entire feature list of Mush; the man page is 50 pages long. But, Mush does provide similar features like "pick" and other functions that MH provides. It does provide "piping" of commands, sorting of messages, etc.. The point is that these features can be provided regardless of the storage method of folders. The fact that many of the features of MH happen to be replicated (there are some very good ones), is a side effect of good design. However, MH has some poor design schemes that warrant the writing of a new MUA. So, I'm not reinventing the wheel with writing Mush, but instead I hope to provide a "new and improved" model. > 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. Believe me, we are aware of what we're doing and are continuing in a well defined direction. There are definite problems with using a Mail-method folder format, but there are an equal number of problems with using the MH-method. One of the major advantages to using the Mail-based folder storage method is that it is backwards compatible with [most] other Mail applications (I address this issue again later). > 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 many things wrong with MH in this respect. Not only is it huge, but it *really is* hard to learn. I remember when I first went to SRI, I was set up with MH by default. I spent hours reading all sorts of doc and experimenting with commands and so on... I was really put off by the fact that all my mail was moved and split up. I struggled with it for a while, but was further put off by the fact that it was so slow. But what really took the cake for me was the fact that if your mail is configured for MH, there's no other UA you can use-- you are stuck with MH. What if I told you I had an editor I'd like you to try but told you that if you used this editor, you can't use any other editor on files you edit using that editor. This is how I see MH's folder format. What saves MH is the fact that there is no "standard" (even proposed standards or RFCs) which discuss folder formats or anything similar. Upon further investigation, I learned that MH wasn't portable to any other unix besides BSD systems. This may have changed lately -- I don't keep up with MH that much (my loss, I guess). Is it true that MH still only talks to sendmail as its sole MTA? > 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. Bad excuse. A good application (regardless of functionality; here we happen to be talking about MUAs) should have a "core" layer which makes the program function _independently_ of its user interface. MH solved the problem by making each MH function a separate shell command. Oy vey... 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*. MH isn't a "library" as you described, but rather a set of commands. You build a "tool" in front of MH by doing a bunch of popen() calls, or system() calls, or whatever... Don't you think that's rather inefficient/expensive? Mush hasn't quite been set up to be totally independent of its user inter- face, but it is so close that it took me effectively two weeks to build the curses interface on it. It also has a suntools interface and a tty (csh-like) shell interface. Building a new front end of Mush is in fact very easy -- it'll even be easier once the implementation of its final design has been completed. The point is, Mush is a library of function calls, not a set of unix commands. > 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. In mush, if you can type "help", you've got it just about licked.. Of course, if you know how to hit "?" that works, too. As simple as you seem to think it is to type "inc", etc..., I never knew to do that when I first learned MH. Despite the doc! > 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. 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. Mush runs on a 80286 running xenix or a ATT PC and more -- can MH? Mush outperforms MH dramatically on large files. For example, finding all messages from a particular author, that has a particular subject, that was sent (or delivered) between two dates from a folder with 500 messages takes about 6-10 seconds. Or, deleting all messages that have been saved takes about 1 second. > Give MH a try. If you hate it, throw it away (or even burn the tape in I'd love to look at it again... But where does one get it? Don't tell me I have to buy it :-). Actually, there's nothing wrong with selling MH (or software, for that matter -- sorry, rms :-), it just means that I won't buy it due to my limited personal financial resources. > 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. As I said, there are good things about MH (altho I didn't get into them here, just note that I recognize them), but I feel that all the good things about MH can be dupicated more efficiently in a different way. Future plans for Mush include supporting MH style folders, news, several inter- face enhancments (more csh-like features) and performance modifications. As you said, MUAs are as religious as using different editors -- you're never going to convince an emacs user to use vi, and chances are unlikely that you're going to convert an MH user to use Mush (altho there are some cases where this has happened :-). > gregg.g.wonderly@att.com (AT&T bell laboratories) dan <island!argv@sun.com> ----- My postings reflect my opinion only -- When on the net, I speak for no company.