davidson%Nosc@sdcsvax.UUCP (04/27/84)
From: Greg Davidson <sdcsvax!davidson@Nosc> The EMAC mail subsystems greatly increase the speed and ease with which I can handle my mail, and I'm delighed by the new ones which know about folders. I am concerned, however, by a tendency to build these systems in such a way that users are left stranded if EMACS breaks, as it has done so reliably with each new version of UNIX. I am also disturbed by a tendency to store messages in such a way that other UNIX tools, user generated shell scripts, etc., can't get to them when you want to do something not available within the system. With these considerations, I prefer systems which store messages either in the old spool file form (appended with no special extra information), or even better, as separate files, which can be turned into a spool file with cat, or handled separately. Storing messages as separate files, and using the usual UNIX directory structure to implement folders allows users the option of either using an EMACS facility to handle their mail, or other UNIX tools when they want to do something fancy not built into the mail system. As I see it, the UNIX programming philosophy is as follows: (1) Create any subroutines needed for the given application, and make them general so other programs can use them for similar tasks. (2) Create one or more programs to do the work, making them as simple as possible, so that they can be combined flexibly with each other, and with existing tools in creative and unexpected ways. They should be non-interactive and take lots of command line options. Power and flexibility, not user convenience, should be the goal here. (3) Create interactive front ends for complex systems, using the programs in (2). Such front ends might just be shell scripts, or they might use curses, or EMACS or whatever. Different users and users in different environments will prefer to use different front ends. EMACS is really great for creating front ends onto existing software. Its computational inefficiency and semantic gaps make it less suitable for implementing whole systems directly in mlisp, and you may have noticed that all of the existing mail systems make use of a set of C programs to do the initial processing of incoming messages, and, of course, to send messages. In this regard, it might be ideal to use an existing mail system to do all of the non-human interaction work, and just use EMACS to implement the front end. An example of a suitable mail system would be mh from Rand, now one of the contributed programs on 4.2BSD. mh is designed to interact gracefully with existing UNIX tools. It stores messages in separate files; folders are just ordinary directories. Best of all, the manipulation functions, including one which creates a summary listing for a folder, are implemented as separate programs. Has anyone put an EMACS front end onto mh? To sum it all up: The UNIX programming style is very powerful, and is a large part of why UNIX is such a successful system. Lets not abandon it, just because we have other powerful tools. -Greg
cak@Purdue.ARPA (04/28/84)
From: Christopher A Kent <cak@Purdue.ARPA> Two someones have put mh into emacs -- Brian Reid at Stanford did "mhe", and Tim Korb at Purdue did "mhi", largely based on inspiration from Brian's work. I don't know what the availability of either of these is, outside the respective home institutions. Cheers, chris ----------
guyton@randvax.ARPA (Jim Guyton) (05/16/84)
I've written a screen-oriented user interface to the Rand MH mail system and we've been using it here at Rand for over a year. It's in C and runs rather faster than an emacs front-end. -- Jim Guyton ...!decvax!randvax!guyton