Xref: utzoo comp.mail.headers:531 comp.mail.misc:2281
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs!boulder!ncar!ames!amdahl!oliveb!sun!eureka!argv
From: argv%eureka@Sun.COM (Dan Heller)
Newsgroups: comp.mail.headers,comp.mail.misc
Subject: Re: MH verses the "all in one file" MUAs
Message-ID: <113567@sun.Eng.Sun.COM>
Date: 8 Aug 89 04:27:48 GMT
References: <113461@sun.Eng.Sun.COM> <1518@cbnewsc.ATT.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: island!argv@sun.com (Dan Heller)
Followup-To: comp.mail.misc
Lines: 202

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 
-----
My postings reflect my opinion only -- When on the net, I speak for no company.