Mercurial > hg > Applications > mh
comparison papers/realwork/text.tex @ 0:bce86c4163a3
Initial revision
| author | kono |
|---|---|
| date | Mon, 18 Apr 2005 23:46:02 +0900 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:bce86c4163a3 |
|---|---|
| 1 % begin text | |
| 2 | |
| 3 \banner | |
| 4 | |
| 5 \section{Introduction} % mtr | |
| 6 The UCI version of the Rand Message Handling System, \MH/, | |
| 7 is a software system that performs two functions: | |
| 8 \underbar{first}, | |
| 9 it interfaces a user to a message transport system, | |
| 10 so the user may receive and send mail; | |
| 11 \underbar{second}, | |
| 12 it permits the user to maintain an organized mail environment to facilitate | |
| 13 the composition of new messages and the reading of old messages. | |
| 14 In short, | |
| 15 while not responsible for the delivery of messages, | |
| 16 \MH/ aids the user in handling mail. | |
| 17 | |
| 18 \MH/ was originally developed by the Rand Corporation, | |
| 19 and initially was proprietary software. | |
| 20 The Department of Information and Computer Science at | |
| 21 University of California, Irvine, | |
| 22 shortly after joining the Computer Science Network (CSnet), | |
| 23 acquired a copy of \MH/, | |
| 24 and began additional development of the software. | |
| 25 Since that time, | |
| 26 the Rand Corporation has declared \MH/ to be in the public domain, | |
| 27 and the UCI version of \MH/ has passed through four major releases. | |
| 28 The current version, \mh5, | |
| 29 is available from U.C.~Irvine for a nominal distribution fee, | |
| 30 or may be retrieved from the University of Delaware via anonymous FTP. | |
| 31 | |
| 32 Much credit must be given to the initial designers and implementors of \MH/: | |
| 33 Bruce Borden, Stockton Gaines, and Norman Shapiro. | |
| 34 Although \MH/ has suffered significant development at UCI | |
| 35 since Rand's initial release, | |
| 36 the fundamental concepts of \MH/'s environs have remained nearly unchanged. | |
| 37 In addition, | |
| 38 the authors of the current release gratefully acknowledge the comments of the | |
| 39 many sites which have run various releases of \MH/ in the past. | |
| 40 In particular, | |
| 41 the dozen or so beta test sites for \mh5 | |
| 42 provided tremendous help in stabilizing the current release. | |
| 43 | |
| 44 \MH/ runs on different versions of the \unix/ operating system | |
| 45 (such as Berkeley~4.2\bsd/ and various flavors of v7). | |
| 46 In addition, | |
| 47 \MH/ supports four different message transport interfaces: | |
| 48 \SendMail/\cite{EAllm83}, | |
| 49 the standard mailer for 4.2\bsd/ systems; | |
| 50 \MMDF/\cite{DCroc79} and \MMDFII/\cite{DKing84}, | |
| 51 the Multi-Channel Memo Distribution Facility developed by the University of | |
| 52 Delaware | |
| 53 which forms the software-backbone for CSnet\cite{DCome83} mail relay service; | |
| 54 SMTP, | |
| 55 the ARPA Internet Simple Mail Transfer Protocol\cite{SMTP}; | |
| 56 and, | |
| 57 a stand-alone delivery system. | |
| 58 | |
| 59 This paper is organized in a straight-forward fashion: | |
| 60 Initially, | |
| 61 the \MH/ philosophy of mail handling is presented, | |
| 62 along with a description of the environment which the \MH/ user is given to | |
| 63 process mail. | |
| 64 Following this, | |
| 65 certain advanced features of \MH/ are discussed in more detail, | |
| 66 such as facilities for selecting messages, | |
| 67 and ``advanced'' concepts in {\it draft} handling. | |
| 68 In addition, | |
| 69 user interface issues in mail handling are addressed, | |
| 70 and the merits of \MH/'s approach is critically examined. | |
| 71 Next, | |
| 72 the \mh5 distribution package is described. | |
| 73 Finally, | |
| 74 we conclude by discussing the authors' experience with \MH/ development | |
| 75 and introducing areas where \MH/ may be further developed. | |
| 76 | |
| 77 Although familiarity with \MH/ is not assumed on the part of the reader, | |
| 78 some knowledge of the \unix/ operating system is useful. | |
| 79 Appendix~A gives a short synopsis of the \MH/ commands. | |
| 80 | |
| 81 \section{The \MH/ Philosophy} % mtr | |
| 82 Although \MH/ has many traits which tend to distinguish it from other systems | |
| 83 which handle mail, | |
| 84 there is a single fundamental design decision which influences the interface | |
| 85 between \MH/ and the user: | |
| 86 \MH/ differs from most other systems in that it is composed of many small | |
| 87 programs instead of one very large one. | |
| 88 This architecture gives \MH/ much of its strength, | |
| 89 since intermediate and advanced users are able to take advantage of this | |
| 90 flexibility. | |
| 91 | |
| 92 The key to this flexibility is that the \unix/ shell | |
| 93 (usually the {\it C} shell or the {\it Bourne} shell), | |
| 94 is the user's interface to \MH/. | |
| 95 This means that when handling mail, | |
| 96 the entire power of the shell is at the user's disposal, | |
| 97 in addition to the | |
| 98 facilities which \MH/ provides. | |
| 99 Hence, | |
| 100 the user may intersperse mail handling commands with other commands in an | |
| 101 arbitrary fashion, | |
| 102 making use of command handling capabilities which | |
| 103 the user's shell provides. | |
| 104 | |
| 105 Furthermore, | |
| 106 rather than storing messages in a complicated data structure | |
| 107 within a monolithic file, | |
| 108 each message in \MH/ is a \unix/ file, | |
| 109 and each folder (an object which holds groups of messages) | |
| 110 in \MH/ is a \unix/ directory. | |
| 111 That is, | |
| 112 the directory- and file-structure of \unix/ is used directly. | |
| 113 As a result, | |
| 114 any \unix/ file-handling command can be applied to any message. | |
| 115 | |
| 116 To the novice, | |
| 117 this may not make much sense or may not seem important. | |
| 118 However, | |
| 119 as users of \MH/ become more experienced, | |
| 120 they find this capability attractive. | |
| 121 In addition, | |
| 122 this approach is often quite pleasing to system implementors, | |
| 123 because it minimizes the amount of coding to be performed, | |
| 124 and given a modular design, | |
| 125 changes to the software system can be maintained easily. | |
| 126 There are, however, performance penalties to be paid with this scheme. | |
| 127 This issue is considered later in the paper. | |
| 128 | |
| 129 Having described how \MH/ fits into the \unix/ environment, | |
| 130 we now discuss the mail handling environment which is available to the \MH/ | |
| 131 user. | |
| 132 | |
| 133 \subsection{The \MH/ Environs} % jlr | |
| 134 In the \file{\$HOME} directory of each \MH/ user, a file named | |
| 135 \profile/ contains static information about the user's \MH/ environment, | |
| 136 and default arguments for \MH/ programs. | |
| 137 For the latter case, | |
| 138 each line of profile takes the form: | |
| 139 \example program-name:\ options\endexample | |
| 140 Each \MH/ program consults the user's \profile/ for its options. | |
| 141 These options are consulted prior to evaluating any command-line arguments, | |
| 142 and so provide the \MH/ user the capability to customize the defaults for each | |
| 143 command. | |
| 144 Futher, by using the \unix/ link facility, | |
| 145 different names can be given to the same command. | |
| 146 Since each \MH/ command looks | |
| 147 in the \profile/ | |
| 148 for a component with the name by which it was invoked, | |
| 149 it's possible to have different defaults for the same program. | |
| 150 For example, | |
| 151 it is not uncommon to link \pgm{prompter} | |
| 152 (a simple prompting editor front-end) | |
| 153 under the name \pgm{rapid} in the | |
| 154 user's \file{bin/} directory, and add to the \profile/: | |
| 155 \example rapid:\ -prepend\ -rapid\endexample | |
| 156 As a result, | |
| 157 when \pgm{prompter} is invoked as \pgm{rapid}, | |
| 158 it automatically uses the \switch{prepend} and \switch{rapid} options. | |
| 159 | |
| 160 The profile component \eg{Path:} is the path to the user's | |
| 161 \MH/-directory, usually \Mail/. | |
| 162 In addition to containing the user's folders, | |
| 163 the \MH/-directory also contains {\it skeletons} and | |
| 164 {\it templates} used by the \MH/ programs, | |
| 165 and the user's \context/ file. | |
| 166 This latter file has the same format as the user's \profile/, | |
| 167 and contains the dynamic, | |
| 168 context-dependent information about the user's environment. | |
| 169 Whenever \MH/ looks for an \MH/-specific file, | |
| 170 such as a template or skeleton, | |
| 171 it first consults the user's \MH/-directory, | |
| 172 and then a system-wide library area. | |
| 173 | |
| 174 The \MH/ user always has a {\it current folder}, | |
| 175 which is the folder in which | |
| 176 the user is currently (or was last) working. | |
| 177 Since any \MH/ program which deals with folders implicitly manipulates this | |
| 178 information, | |
| 179 the name of the current folder is stored in the \file{context} | |
| 180 component \eg{Current-Folder:}. | |
| 181 Every folder has a {\it current message} known as \arg{cur}. | |
| 182 These values are the defaults for \MH/ commands which | |
| 183 accept folder and/or messages arguments. | |
| 184 | |
| 185 \MH/ programs make use of a set of envariables | |
| 186 which further customize their behavior. | |
| 187 The \file{\$MH} envariable, if present, | |
| 188 specifies the name of an alternate profile for the user. | |
| 189 This allows a user of \MH/ to | |
| 190 easily maintain multiple mail-handling environments. | |
| 191 | |
| 192 In terms of command syntax, | |
| 193 most \MH/ commands accept an optional {\it folder} argument, | |
| 194 such as \arg{+outbox}. | |
| 195 Unlike most \unix/ commands, | |
| 196 all \MH/ commands have switches which are words, rather than single letters. | |
| 197 Switches may be abbreviated to the least unambiguous prefix. | |
| 198 All \MH/ commands also support a \switch{help} switch, | |
| 199 which lists the syntax of the command along with available switches, | |
| 200 and the version number of the command. | |
| 201 Most \MH/ commands also take a \arg{msg} or \arg{msgs} argument | |
| 202 which takes the form of a message number (\eg{1}), a message range (\eg{1-2}), | |
| 203 a standard sequence name (\eg{cur}), | |
| 204 or a user-defined sequence name (\eg{select}). | |
| 205 | |
| 206 \tagdiagram{1}{An \MH/ Session}{session} | |
| 207 \subsection{An \MH/ Transcript} % jlr | |
| 208 Figure~\session\ contains a transcript of a simple \MH/ session. | |
| 209 First, \pgm{inc} is run to incorporate the new mail into the | |
| 210 user's \eg{+inbox} folder. | |
| 211 | |
| 212 A \pgm{scan} listing of the mail is printed while | |
| 213 it is being incorporated. | |
| 214 (The user could run \pgm{scan} explicitly to generate additional \pgm{scan} | |
| 215 listings later on.) | |
| 216 The \pgm{scan} listing gives the message number, followed | |
| 217 by the date, message sender, and subject. | |
| 218 (If the message originated from the user generating the listing, | |
| 219 the \eg{to:} addressee is displayed instead of the sender.) | |
| 220 If the subject is short, | |
| 221 the first part of the message body is displayed after the characters \eg{<<}. | |
| 222 The plus sign (`+') after | |
| 223 the message number indicates the current message. | |
| 224 | |
| 225 The user \pgm{show\/}s the message, and decides to \pgm{repl\/}y. | |
| 226 A reply draft | |
| 227 is created using the headers of the message being replied-to, | |
| 228 using the default \file{replcomps} template. | |
| 229 The default editor, \pgm{prompter}, is called to edit the draft. | |
| 230 When an EOT is typed, \pgm{prompter} exits and the | |
| 231 user is left at the \whatnow/ prompt. | |
| 232 The option \pgm{send} is chosen. | |
| 233 Since there were no problems in posting the draft with the message transport | |
| 234 system, | |
| 235 no additional output is produced. | |
| 236 (\MH/ is not verbose by default.) | |
| 237 | |
| 238 The user then decides to compose a new message. | |
| 239 The default skeleton, \file{components}, is copied to the draft, | |
| 240 and \pgm{prompter} is once again called. | |
| 241 After entering the addresses, subject, and body, | |
| 242 the user then \pgm{send\/}s the \file{draft} from the \whatnow/ prompt, | |
| 243 using \eg{send\ -verbose}, which causes | |
| 244 \MH/ to list out the message addresses as it submits them | |
| 245 to the message transport system. | |
| 246 | |
| 247 \section{Some \MH/ Features} % mtr | |
| 248 We now consider certain advanced features in \MH/. | |
| 249 These features have been chosen to demonstrate some useful capabilities | |
| 250 available to the \MH/ user. | |
| 251 | |
| 252 \subsection{Message Sequences and Selection} % jlr | |
| 253 \MH/ has several built-in message sequence names, which may | |
| 254 be used anywhere a \arg{msg} or \arg{msgs} argument is expected. | |
| 255 These are: | |
| 256 \arg{cur}, \arg{next}, \arg{prev}, \arg{first}, \arg{last}, and \arg{all}. | |
| 257 Message ranges may also be specified. | |
| 258 For example, \arg{all} is actually \arg{first-last}, and | |
| 259 \arg{+mh\ last:5} references the last five messages in your | |
| 260 \arg{+mh} folder. | |
| 261 A powerful capability of \MH/ is the ability to use not only the pre-defined | |
| 262 message sequence names, | |
| 263 but also arbitrary user-defined message sequence names. | |
| 264 | |
| 265 Although all \MH/ programs recognize user-defined sequences when appropriate, | |
| 266 the \pgm{pick} and \pgm{mark} commands can create and modify | |
| 267 user-defined message sequences. | |
| 268 The \pgm{mark} command allows low-level manipulation of sequences, | |
| 269 and is not particularly interesting in our discussion. | |
| 270 | |
| 271 The \pgm{pick} command selects certain messages out of a folder. | |
| 272 The criteria used for selection may be a search string and/or a date range. | |
| 273 | |
| 274 Searching is performed on either a specific header in the message | |
| 275 (e.g., \eg{To:}), | |
| 276 or anywhere within the message. | |
| 277 By default, | |
| 278 \pgm{pick} lists out the message numbers that matched | |
| 279 the selection criteria. | |
| 280 Thus, \pgm{pick} is useful in backquoted operations to the shell. | |
| 281 For example, to scan all the messages in the current folder from ``frated'', | |
| 282 the \MH/ user issues the command: | |
| 283 \example scan\ \bq{pick\ -from\ frated}\endexample | |
| 284 To perform more complicated message selection, | |
| 285 user-defined sequences are employed. | |
| 286 Supplying a \switch{sequence\ name} | |
| 287 argument to \pgm{pick}, will cause it to define the | |
| 288 sequence \arg{name} as those messages matched. | |
| 289 | |
| 290 Giving \pgm{pick} a list of messages causes it to limit its search to just | |
| 291 those messages. | |
| 292 For example, | |
| 293 to find all the messages in the current folder from ``frated'' also dated | |
| 294 before friday: | |
| 295 \example pick\ -from\ frated\ -sequence\ select\\ | |
| 296 pick\ select\ -before\ friday\ -sequence\ select\endexample | |
| 297 With the first \pgm{pick} command, | |
| 298 the sequence \eg{select} is defined | |
| 299 to be all those messages from ``frated''. | |
| 300 In the second command, only those messages already in the \eg{select} | |
| 301 sequence are searched, and the \eg{select} sequence is redefined to be | |
| 302 only those messages which are also | |
| 303 dated before friday. | |
| 304 Those messages could then be \pgm{show\/}n with: | |
| 305 \example show\ select\endexample | |
| 306 When a \switch{sequence\ name} argument is given to \pgm{pick}, | |
| 307 the default behavior --- listing the message numbers | |
| 308 matched --- is inhibited. | |
| 309 To re-enable this behavior, the \switch{list} option may be given. | |
| 310 As a result, | |
| 311 advanced users of \MH/ often put the following line in their \profile/: | |
| 312 \example pick:\ -sequence\ select\ -list\endexample | |
| 313 which allows them to easily make use of the \arg{select} sequence as the | |
| 314 messages last selected with \pgm{pick}. | |
| 315 | |
| 316 Often it is desirable to act upon those messages which | |
| 317 are {\it not} members of a given sequence. | |
| 318 For this purpose, | |
| 319 the \eg{Sequence-Negation:} profile entry is useful. | |
| 320 If the name of a user-defined sequence is prefixed with the value of the | |
| 321 sequence-negation profile entry, | |
| 322 \MH/ commands will operate upon those messages which are {\it not} members | |
| 323 of that sequence. | |
| 324 For example, given a profile entry of: | |
| 325 \example Sequence-Negation:\ not\endexample | |
| 326 those messages which | |
| 327 are not in the \arg{select} sequence could be \pgm{scan\/}'d with: | |
| 328 \example scan\ notselect\endexample | |
| 329 | |
| 330 Obviously, some confusion could result if an attempt was made | |
| 331 to define a sequence name | |
| 332 which began with the sequence-negation string (e.g., \eg{notselect}). | |
| 333 For this reason, \MH/ users will often use a single | |
| 334 character, | |
| 335 which their shell doesn't interpret, | |
| 336 as their sequence-negation string | |
| 337 (e.g., up-caret (`\^{}') for {\it C} Shell users, | |
| 338 and exclamation-mark (`!') for {\it Bourne} shell users). | |
| 339 | |
| 340 \MH/ also provides a way of automatically remembering the last | |
| 341 message list given to | |
| 342 an \MH/ command. | |
| 343 This facility is implemented by using a profile entry called | |
| 344 \eg{Previous-Sequence:}. | |
| 345 | |
| 346 \subsection{Draft Handling} % jlr | |
| 347 After the initial edit of a message draft, | |
| 348 the \pgm{comp}, \pgm{dist}, \pgm{forw}, and \pgm{repl} programs | |
| 349 give the user a \whatnow/ prompt. | |
| 350 The valid responses include: | |
| 351 \pgm{edit} to re-edit the draft, | |
| 352 \pgm{quit} to exit without sending the draft, | |
| 353 \pgm{send} to send the draft, and | |
| 354 \pgm{push} to send the draft in the background. | |
| 355 | |
| 356 When the \pgm{send} option is given, | |
| 357 the draft is posted with the message transport system. | |
| 358 If there problems posting the draft, | |
| 359 the \whatnow/ prompt is re-issued, | |
| 360 so errors in the draft may be corrected. | |
| 361 | |
| 362 Since posting the draft can be slow, | |
| 363 the \pgm{push} option allows the \MH/ user to send the draft in the | |
| 364 background, and return immediately to the shell. | |
| 365 If there are problems posting the message, | |
| 366 the user will not see the diagnostics produced by | |
| 367 the message transport system. | |
| 368 For this reason, | |
| 369 if \pgm{push} is used instead of \pgm{send}, | |
| 370 and the message is not successfully posted, | |
| 371 \MH/ mails a message to the user | |
| 372 containing any diagnostics which the message transport system produced | |
| 373 along with a copy of the message. | |
| 374 Later, | |
| 375 the draft may be re-edited by entering \eg{comp\ -use}. | |
| 376 | |
| 377 A relatively new feature of \MH/ is the ability to use a folder to store | |
| 378 multiple drafts. | |
| 379 These drafts are kept in an ordinary \MH/ folder, | |
| 380 and may be operated upon by \MH/ commands. | |
| 381 To enable this feature, | |
| 382 the \MH/ user selects a folder-name for the draft-folder, | |
| 383 and creates an entry in the \profile/: | |
| 384 \example Draft-Folder:\ +foldername\endexample | |
| 385 From this point on, | |
| 386 when a message is composed, | |
| 387 the draft will be created as a message in that folder, | |
| 388 instead of using the \file{draft} file in the user's \MH/ directory. | |
| 389 Unfortunately, | |
| 390 if posting problems occur on a message which has been \pgm{push\/}'d, | |
| 391 it may be difficult to re-edit the draft with | |
| 392 \eg{comp\ -use}. | |
| 393 This might be the case if the user had started composing another message, | |
| 394 while that first draft was being posted. | |
| 395 In that event, | |
| 396 the current-message in the draft-folder would no longer point | |
| 397 to the failed draft. | |
| 398 | |
| 399 There is a solution for this problem, however. | |
| 400 By default, | |
| 401 \pgm{push} assumes the \switch{forward} option, | |
| 402 which says that if the message draft fails to be posted, | |
| 403 it should be forwarded back to the user in the | |
| 404 error report which \pgm{push} generates. | |
| 405 The failed draft may then be extracted with the \pgm{burst} program | |
| 406 (discussed later). | |
| 407 | |
| 408 \subsection{BBoards} % mtr | |
| 409 \MH/ has a convenient interface to the UCI BBoards facility\cite{MRose84a}.% | |
| 410 \nfootnote{The UCI BBoards facility can run under either the \MMDF/ or | |
| 411 \SendMail/, | |
| 412 or in a more restricted form under stand-alone \MH/.} | |
| 413 This facility permits the efficient distribution of interest group messages | |
| 414 on a single host, | |
| 415 to a group of hosts under a single administration, | |
| 416 and to the ARPA Internet community. | |
| 417 | |
| 418 Although most readers are probably familiar with the concept of an interest | |
| 419 group in the Internet context, a brief description is now given. | |
| 420 Observant readers will notice that the distributed nature of the | |
| 421 ``network news'' (a.k.a.~USENET) | |
| 422 tends to avoid many of the problems described below. | |
| 423 | |
| 424 Described simply, an interest group is composed of a number of subscribers | |
| 425 with a common interest. | |
| 426 These subscribers post mail to a single address, known as the | |
| 427 {\it distribution} address (e.g., {\tx MH-Workers@UCI}. | |
| 428 From this distribution address, a copy of the message is sent to each | |
| 429 subscriber. | |
| 430 Each group has a {\it moderator}, | |
| 431 who is the person that runs the group. | |
| 432 This moderator can usually be reached at a special address, | |
| 433 known as the {\it request} address (e.g., {\tx MH-Workers-Request@UCI}). | |
| 434 Usually, the responsibilities of the moderator are quite simple, | |
| 435 since the mail system handles distribution to subscribers automatically. | |
| 436 In some interest groups, | |
| 437 instead of each separate message being distributed directly to subscribers, | |
| 438 a batch of (hopefully related) messages | |
| 439 are put into a {\it digest} format by the | |
| 440 moderator and then sent to the subscribers. | |
| 441 (This is similar to a newsletter format.) | |
| 442 Although this requires more work on the part of the moderator | |
| 443 and introduces delays, | |
| 444 such groups tend to be better organized. | |
| 445 | |
| 446 Unfortunately, some problems arise with the scheme outlined above. | |
| 447 First, if two users on the same host subscribe to the same interest group, | |
| 448 two copies of the message are delivered. | |
| 449 This is wasteful of both processor and disk resources at that host. | |
| 450 | |
| 451 Second, | |
| 452 some groups carry a lot of traffic. | |
| 453 Although subscription to a group does indicate interest on the part of a | |
| 454 subscriber, | |
| 455 it is usually not interesting to get 50 or so messages delivered | |
| 456 each day | |
| 457 to the user's private maildrop, | |
| 458 interspersed with {\it personal} mail, | |
| 459 which is likely to be of a much more important and timely nature. | |
| 460 | |
| 461 Third, if a subscriber's address in a distribution list | |
| 462 becomes ``bad'' somehow and causes failed mail to be returned, | |
| 463 the originator of the message is normally notified. | |
| 464 It is not uncommon for a large list to have several bogus addresses. | |
| 465 This results in the originator being flooded with ``error messages'' from | |
| 466 mailers across the Internet stating that a given address on the list was | |
| 467 bad. | |
| 468 Needless to say, | |
| 469 the originator usually does not care if the bogus addresses got a copy | |
| 470 of the message or not. | |
| 471 The originator is merely interested in posting a message | |
| 472 to the group at large. | |
| 473 On the other hand, | |
| 474 the moderator of the group does care if there are bogus addresses on the list, | |
| 475 but ironically does not receive notification. | |
| 476 | |
| 477 To solve these problems, | |
| 478 the UCI BBoards facility introduces a new entity into the picture: | |
| 479 a {\it distribution channel}. | |
| 480 All interest group mail is handled by | |
| 481 the special mail system component. | |
| 482 The distribution address for an interest-group | |
| 483 maps mail for that interest-group to the distribution channel, | |
| 484 which then performs | |
| 485 several actions. | |
| 486 First, if local delivery is to be performed, | |
| 487 a copy of the message is placed in a global maildrop for the interest | |
| 488 group with a timestamp and a unique number. | |
| 489 Local users can read messages posted for the interest group by reading this | |
| 490 ``public'' maildrop. | |
| 491 Second, if further distribution is to take place, | |
| 492 a copy of the message is sent to the distribution address in such a way that | |
| 493 if any of the addresses are bogus, | |
| 494 failure notices will be returned to the local maintainer of the group | |
| 495 address list, rather than the originator of the message. | |
| 496 | |
| 497 This scheme has several advantages: | |
| 498 First, messages delivered to the local host are processed and saved once | |
| 499 in a globally accessible area. | |
| 500 The UCI BBoards facility supports software which allows a user to query an | |
| 501 interest group for new messages and to read and process | |
| 502 those messages in the \MH/-style. | |
| 503 Second, once a host administrator subscribes to an interest group, | |
| 504 each user may join or quit the list's readership without | |
| 505 contacting anyone. | |
| 506 Third, a hierarchical distribution scheme can be constructed to | |
| 507 reduce the amount of delivery effort. | |
| 508 Finally, errors are prevented from propagating. | |
| 509 When an address on the distribution list goes bad, | |
| 510 the list moderator who is responsible for the address is notified. | |
| 511 If a local moderator does not exist, | |
| 512 then the local PostMaster is notified (not the global group moderator). | |
| 513 | |
| 514 In addition to solving the problems outlined above, | |
| 515 the UCI BBoards facility supports several other capabilities. | |
| 516 BBoards may be automatically archived in order to conserve disk space and | |
| 517 reduce processing time when reading current items. | |
| 518 Also, | |
| 519 the archives can be separately maintained on tape for access by interested | |
| 520 researchers. | |
| 521 | |
| 522 Special alias files may be generated which allow the \MH/ user to shorten | |
| 523 address entry. | |
| 524 For example, instead of sending to {\tx SF-Lovers@Rutgers}, | |
| 525 a user of \MH/ usually sends to \eg{SF-Lovers} and the \MH/ aliasing | |
| 526 facility automatically makes the appropriate expansion in the headers of the | |
| 527 outgoing message. | |
| 528 Hence, | |
| 529 the user need only know the name of an interest group and not its global | |
| 530 network address. | |
| 531 | |
| 532 Finally, the UCI BBoards facility supports {\it private} interest groups | |
| 533 using the \unix/ group access mechanism. | |
| 534 This allows a group of people on the same or different machines to conduct a | |
| 535 private discussion. | |
| 536 | |
| 537 The practical upshot of all this is that the UCI BBoards facility automates | |
| 538 the vast majority of BBoards handling from the point of view of both the | |
| 539 PostMaster and the user. | |
| 540 | |
| 541 \MH/ provides three programs to deal with interest groups. | |
| 542 The \pgm{bbc} program is used to check on the status of one or more groups, | |
| 543 and to optionally start an \MH/ shell on those groups which the user is | |
| 544 interested in. | |
| 545 The \pgm{bbl} program can be used to manually perform maintenance on a | |
| 546 discussion group beyond the normal automatic capabilities of the UCI BBoards | |
| 547 facility. | |
| 548 Finally, | |
| 549 the \pgm{msh} program implements an \MH/ shell for reading BBoards, | |
| 550 in which nearly all of the \MH/ commands are implemented in a single program. | |
| 551 | |
| 552 Observant readers may note that the use of \pgm{msh} is contrary to the \MH/ | |
| 553 philosophy of using relatively small, single-purpose programs. | |
| 554 Sadly, | |
| 555 the authors admit that this is true. | |
| 556 In an effort to minimize use of system resources however, | |
| 557 BBoards are kept in maildrop format instead of folders.% | |
| 558 \nfootnote{When the message transport system delivers a message to a user | |
| 559 it stores it in a single file, called a {\it maildrop}. | |
| 560 Since many messages may be present in a single maildrop, | |
| 561 (in theory) there is a unique string acting as a separator between messages | |
| 562 in the maildrop. | |
| 563 Although this is convenient for storage of messages, | |
| 564 it makes retrieval more difficult unless a separate index into the maildrop | |
| 565 is kept. | |
| 566 This latter approach is taken by the \pgm{msg} program available with \MMDFII/ | |
| 567 and by \pgm{msh} as well.} | |
| 568 Some research has gone into overcoming this problem to restore | |
| 569 \MH/'s purity of purpose, | |
| 570 but all solutions proposed to date are either unworkable or require | |
| 571 significant recoding of \MH/'s internals. | |
| 572 | |
| 573 \subsection{Bursting} % jlr | |
| 574 Internet interest group mail is often sent out in digest form. | |
| 575 The experienced \MH/ user may wish to deal with the digest messages on | |
| 576 an individual basis, however. | |
| 577 The \pgm{burst} program allows the \MH/ user to extract these digest | |
| 578 messages, | |
| 579 and store each as an individual \MH/ message. | |
| 580 | |
| 581 \pgm{Burst} will also extract forwarded messages generated by \pgm{forw} | |
| 582 (or the forwarded message in the error report generated by \pgm{push}, | |
| 583 as described above). | |
| 584 Although \pgm{burst} cannot always decapsulate | |
| 585 messages encapsulated by sites not running \MH/, | |
| 586 it adheres to the proposed standard described in \cite{MRose85b}. | |
| 587 | |
| 588 \subsection{Distributed Mail} % mtr | |
| 589 The ARPA Internet community consists of many types of heterogeneous nodes. | |
| 590 Some hosts are large mainframe computers, | |
| 591 others are personal workstations. | |
| 592 All communicate using the \milstd/ TCP/IP protocol suite\cite{IP,TCP}. | |
| 593 Messages which conform to the Standard for the Format of ARPA Internet Text | |
| 594 Messages\cite{DCroc82} | |
| 595 are exchanged using the Simple Mail Transfer Protocol\cite{SMTP}. | |
| 596 | |
| 597 On smaller nodes in the ARPA Internet, | |
| 598 it is often impractical to maintain | |
| 599 a message transport system (e.g., \SendMail/). | |
| 600 For example, | |
| 601 a workstation may not have sufficient resources (cycles, disk space) | |
| 602 in order to permit an SMTP server and associated local mail delivery system | |
| 603 to be kept resident and continuously running. | |
| 604 Furthermore, | |
| 605 the workstation could be off-net for extended periods of time. | |
| 606 Similarly, | |
| 607 it may be expensive (or impossible) to keep a personal computer | |
| 608 interconnected to an IP-style network for long periods of time. | |
| 609 In other words, | |
| 610 the node is lacking the resource known as ``connectivity''. | |
| 611 | |
| 612 Despite this, | |
| 613 it is often desirable to be able to manage mail with \MH/ on these smaller | |
| 614 nodes, | |
| 615 and they often support a user agent to aid the tasks of mail handling. | |
| 616 To solve this problem, | |
| 617 a network node which can support a message transport entity | |
| 618 (known as {\it service} host) offers | |
| 619 a maildrop service to these less endowed nodes | |
| 620 (known as {\it client} hosts). | |
| 621 The Post Office Protocol\cite{JReyn84} (POP) is intended to permit a | |
| 622 workstation to dynamically access a maildrop on a service host to pick-up | |
| 623 mail.% | |
| 624 \nfootnote{Actually, | |
| 625 there are three different descriptions of the POP. | |
| 626 The first, cited in \cite{JReyn84}, | |
| 627 was the original description of the protocol, | |
| 628 which suffered from certain problems. | |
| 629 Since then, | |
| 630 two alternate descriptions have been developed. | |
| 631 The official revision of the POP\cite{MButl85}, | |
| 632 and the revision of the POP which \MH/ uses | |
| 633 (which is documented in an internal memorandum in the \MH/ release). | |
| 634 This paper considers the POP in the context of the \MH/ release.} | |
| 635 The level of access includes the ability to | |
| 636 determine the number of messages in the maildrop and the size of each message, | |
| 637 as well as to retrieve and delete individual messages. | |
| 638 More sophisticated implementations of the POP server | |
| 639 are able to distinguish between the header and body portion of each message, | |
| 640 and send $n$ lines of a message to the POP client. | |
| 641 This capability is useful in thinly connected environments where conservation | |
| 642 of bandwidth is important. | |
| 643 By utilizing a more intelligent POP client, | |
| 644 a user may generate ``scan~listings'' and decide dynamically which messages | |
| 645 are worth taking delivery on. | |
| 646 The philosophy of the POP is to put intelligence in the | |
| 647 POP clients and not the POP servers. | |
| 648 | |
| 649 The current release of \MH/ supports the above model fully. | |
| 650 A POP client program is available to retrieve a maildrop from a POP service | |
| 651 host. | |
| 652 In addition, | |
| 653 using the SMTP configuration for delivery in \MH/ | |
| 654 (either in conjunction with \SendMail/ or the \MMDF/), | |
| 655 a user is able to specify a search-list of service hosts (and/or networks) | |
| 656 to try to post mail. | |
| 657 Using this search-list, | |
| 658 when an \MH/ user posts a draft, | |
| 659 the \pgm{post} program will attempt to establish an SMTP connection | |
| 660 with each host in the search-list to post the message until it succeeds. | |
| 661 Initial experimentation using the POP and \MH/ | |
| 662 in a local network environment has proved quite successful. | |
| 663 | |
| 664 \section{User Interface Issues in \MH/} % mtr | |
| 665 At this point, | |
| 666 it is perhaps useful to take a step backwards and examine the success | |
| 667 and problems of \MH/'s approach to user interfaces. | |
| 668 | |
| 669 \subsection{Creeping Featurism} % mtr | |
| 670 A complaint often heard about systems which undergo substantial development | |
| 671 by many people over a number of years, is that more and more options are | |
| 672 introduced which add little to the functionality but greatly increase the | |
| 673 amount of information a user needs to know in order to get useful work done. | |
| 674 This is usually referred to as {\it creeping featurism}. | |
| 675 | |
| 676 Unfortunately \MH/, | |
| 677 having undergone six years of off-and-on development by ten or so | |
| 678 well-meaning programmers (the present authors included), | |
| 679 suffers mightily from this. | |
| 680 For example, | |
| 681 the \pgm{send} command has twenty-five visible switches, | |
| 682 and at least nine hidden switches, | |
| 683 for a total of thirty-four. | |
| 684 The poor user who types \example send\ -help\endexample watches the options | |
| 685 scroll off the screen | |
| 686 (since the \switch{help} switch also lists out four other lines of | |
| 687 information).% | |
| 688 \nfootnote{Recently, | |
| 689 this was fixed by compressing the way in which switches are presented. | |
| 690 The solution is only temporary however, | |
| 691 as \pgm{send} will no doubt acquire an {\it endless} number of switches in | |
| 692 the years to come.} | |
| 693 The sad part is that all of these switches are useful in one form or another. | |
| 694 | |
| 695 There are a lot of good things to be said for the | |
| 696 ``one program, one function'' philosophy of system design. | |
| 697 In the \MH/ case, however, | |
| 698 each program really does only one mail handling activity | |
| 699 (with a few minor exceptions). | |
| 700 The options associated with each command are present to modify the program's | |
| 701 behavior to perform similar, but slightly different tasks. | |
| 702 In further defense of \MH/, | |
| 703 note that there are~32 \MH/ commands at present, | |
| 704 all performing different tasks. | |
| 705 | |
| 706 The problem with creeping featurism though, | |
| 707 is that while the functionality of the system increases sub-linearly, | |
| 708 the complexity of the system increases linearly. | |
| 709 That is, | |
| 710 although the number of switches that a program takes might double, | |
| 711 it is unlikely that the program's functionality or capabilities will double. | |
| 712 | |
| 713 \subsection{Templates versus Switches} % mtr | |
| 714 One way to trim the explosion of available options, | |
| 715 while still increasing functionality, | |
| 716 is to introduce options with a richer domain. | |
| 717 Hence, | |
| 718 instead of using options which take {\it on} or {\it off} forms | |
| 719 or simple numeric or string values, | |
| 720 the possible values which an option might take on is given a large space. | |
| 721 There are several ways that this might be accomplished. | |
| 722 | |
| 723 \tagdiagram{2}{Draft Skeleton}{components} | |
| 724 The \pgm{comp}, \pgm{dist}, and \pgm{forw} programs | |
| 725 use draft {\it skeletons} (simple form fill-in files) to construct the | |
| 726 general format of the draft being composed. | |
| 727 An example of a draft skeleton used for composing new messages | |
| 728 (by \pgm{comp\/}) is shown in Figure~\components. | |
| 729 The approach is to let the user specify (and later edit) both arbitrary | |
| 730 headers of draft and the body of the draft. | |
| 731 Note while most of the fields are empty, | |
| 732 the first \eg{Fcc:} field already contains a value. | |
| 733 By using the simple prompting editor, \pgm{prompter}, | |
| 734 the user can speedily enter the headers of the message. | |
| 735 The \pgm{prompter} program given the skeleton in Figure~\components\ would | |
| 736 prompt the user for the contents of each field, | |
| 737 except for the second \eg{fcc:}, | |
| 738 which it would include verbatim. | |
| 739 It would then read the body of the message up to an end-of-file. | |
| 740 Naturally, | |
| 741 the \MH/ user is free to use {\it any} editor to edit {\it any} part of the | |
| 742 draft (headers or body). | |
| 743 This example | |
| 744 demonstrates the flexibility achieved by not limiting what headers a | |
| 745 draft may contain (which most mail sending programs do), | |
| 746 while still retaining the simplicity of being able to treat the entire | |
| 747 message draft as a \unix/ file. | |
| 748 | |
| 749 \tagdiagram{3}{Reply Template}{replcomps} | |
| 750 Another more interesting approach is used by the \pgm{repl} command, | |
| 751 which constructs a draft in reply-to a previously received message. | |
| 752 Instead of adding switches to indicate which fields of the draft should be | |
| 753 derived from the message being replied-to, | |
| 754 and how they should be derived, | |
| 755 a single option, | |
| 756 the ability to specify a {\it template}, was made available. | |
| 757 An example of a reply template is shown in Figure~\replcomps. | |
| 758 Put simply, | |
| 759 based on the presence of certain fields in the message being replied-to, | |
| 760 and a few switches given by the user, | |
| 761 using the reply template, | |
| 762 \pgm{repl} generates the reply draft automatically. | |
| 763 | |
| 764 \tagdiagram{4}{The \file{tripcomps} Reply Template}{tripcomps} | |
| 765 This facility, for example, | |
| 766 can be used to generate automatic replies.% | |
| 767 \nfootnote{\MH/ supports the notion of a user-defined {\it mail hook} | |
| 768 which is invoked each time a user receives mail.} | |
| 769 One function might be to write a \pgm{rcvtrip} shell script | |
| 770 which automatically answered messages when mail wasn't being read for a | |
| 771 period of time | |
| 772 (e.g., while attending a conference). | |
| 773 An example of a reply template at the heart of such a script | |
| 774 is shown in Figure~\tripcomps. | |
| 775 | |
| 776 \tagdiagram{5}{The \file{bombcomps} Reply Template}{bombcomps} | |
| 777 Finally, | |
| 778 another application might be to utilize | |
| 779 the highly useful letter bomb protocol.% | |
| 780 \nfootnote{The authors wish to credit Ron Natalie of the Ballistics Research | |
| 781 Laboratory in Aberdeen, Maryland for formalizing the | |
| 782 use of this protocol in the ARPA Internet community.} | |
| 783 The important thing to note about this template is that it generates not only | |
| 784 the headers of the reply draft (with a creative \eg{Reply-to:} address), | |
| 785 but the body as well. | |
| 786 Hence, | |
| 787 the commands | |
| 788 \example | |
| 789 repl\ -form\ bombcomps\ -noedit\ ;\ rmm\\ | |
| 790 What\ now?\ push% | |
| 791 \endexample | |
| 792 are very handy for dealing with disturbing mail in a straight-forward manner. | |
| 793 Of course, \pgm{repl} could be linked to \pgm{bomb} in the user's \file{bin/} | |
| 794 directory and an appropriate line could be added to the user's \MH/ profile, | |
| 795 in order to further shorten type-in. | |
| 796 | |
| 797 \tagdiagram{6}{Display Template}{mhlforward} | |
| 798 A variation on the reply template is the {\it display template}. | |
| 799 A display template, as used by the \pgm{mhl} program, | |
| 800 contains instructions on how to format a message. | |
| 801 In addition to being used by \pgm{show}, et.~al., | |
| 802 the \pgm{forw} program can also use a display template to format each | |
| 803 message being forwarded. | |
| 804 Similarly, | |
| 805 although \pgm{repl} uses a reply template to construct the draft | |
| 806 being composed, | |
| 807 it also may use a display template to format the body of the message | |
| 808 being replied-to for enclosure in the reply. | |
| 809 Furthermore, | |
| 810 the \pgm{post} program may use a display template to format the body of a | |
| 811 blind-carbon-copy. | |
| 812 An example of a display template used for formatting forwarded messages | |
| 813 is shown in Figure~\mhlforward. | |
| 814 | |
| 815 As with reply templates, | |
| 816 display templates can offer a lot of functionality. | |
| 817 For example, | |
| 818 the one line display template: | |
| 819 \example | |
| 820 body:nocomponent,overflowtext=,overflowoffset=0,width=10000% | |
| 821 \endexample | |
| 822 can be used to extract the body of a message, | |
| 823 while ignoring the headers. | |
| 824 Hence, | |
| 825 if a \pgm{shar} archive arrived in the mail, | |
| 826 a convenient way to unpack it, | |
| 827 assuming the above display template was called \file{mhl.body}, | |
| 828 would be: | |
| 829 \example show\ -form\ mhl.body\ |\ sh\endexample | |
| 830 | |
| 831 The biggest win with display templates, | |
| 832 of course, | |
| 833 is that all those annoying header lines which mailers | |
| 834 everywhere generate can be simply and easily filtered out. | |
| 835 | |
| 836 \subsection{Modularity versus Monolithicity} % jlr | |
| 837 Since \MH/ is a set of programs | |
| 838 which perform separate tasks, | |
| 839 as opposed to being a single, monolithic program, | |
| 840 the power of the shell is used directly to aid in mail-handling. | |
| 841 One powerful capability which this design achieves is the ability to extend | |
| 842 the \MH/ command set, | |
| 843 by developing shell scripts which use the standard \MH/ | |
| 844 programs to accomplish complicated or specialized tasks. | |
| 845 | |
| 846 \tagdiagram{7}{The \pgm{mpick} Script}{mpick} | |
| 847 For example, | |
| 848 in the \MH/ distribution there is a shell script | |
| 849 called \pgm{mpick} (shown in Figure~\mpick) | |
| 850 which tries to locate all the messages which pertain to a given discussion, | |
| 851 by looking at the \eg{Message-ID:} and \eg{In-reply-to:} headers, | |
| 852 to find matching message-ids.% | |
| 853 \nfootnote{Note that the shell scripts included in the \MH/ distribution | |
| 854 are written for the {\it Bourne} shell, | |
| 855 and have a `:' as the first character of the first line, | |
| 856 so they will be portable to all versions of \unix/, | |
| 857 not just those which support the | |
| 858 Berkeley `\#!' enhancement.} | |
| 859 | |
| 860 \tagdiagram{8}{The \pgm{append} Editor}{appended} | |
| 861 Unfortunately, some parts of \MH/ are somewhat monolithic. | |
| 862 An example of this is the \whatnow/ prompt. | |
| 863 There are only a few options at this prompt, | |
| 864 and one cannot give a normal shell command. | |
| 865 Some \MH/ users seem to feel that more options should be added to | |
| 866 the \whatnow/ prompt, such as an \pgm{insert-file} option. | |
| 867 It was argued that just about any editor would allow you to | |
| 868 insert a file, and another \whatnow/ option was not needed. | |
| 869 These users persisted, however, so the | |
| 870 problem was solved, by writing a trivial shell | |
| 871 script ``editor'' (see Figure~\appended) | |
| 872 which could be invoked by the \pgm{edit} option: | |
| 873 \example What now?\ edit\ append\ filename\endexample | |
| 874 | |
| 875 A better interface at this point is really needed, however. | |
| 876 One possibility is to simply pass any unrecognized commands on | |
| 877 to a shell for interpretation, supplying the path name of the draft file | |
| 878 as an argument. | |
| 879 A solution which shows more promise is to give you a sub-shell | |
| 880 {\it instead} of the \whatnow/ prompt, | |
| 881 and setup certain envariables so that | |
| 882 the \MH/ commands would act upon the \file{draft} by default. | |
| 883 For example, \pgm{show} with no \arg{msgs} arguments | |
| 884 would show the draft instead of the current message. | |
| 885 This alternative has recently been implemented and is under testing. | |
| 886 | |
| 887 \section{The \MH/ Distribution} % mtr | |
| 888 The \mh5 distribution is now briefly described, | |
| 889 both in terms of static configuration methods | |
| 890 and dynamic tailoring. | |
| 891 Appendix~B describes the mechanics of receiving an \mh5 distribution. | |
| 892 | |
| 893 \subsection{Configurable \MH/} % jlr | |
| 894 The \MH/ distribution currently runs on a large number of different \unix/ | |
| 895 versions, | |
| 896 ranging from MicroSoft XENIX to Berkeley 4.2\bsd/. | |
| 897 All the code which is specific to a particular target environment is | |
| 898 enabled via the C-preprocessor \eg{\#ifdef} mechanism, | |
| 899 so compilation under different versions of \unix/ is trivial. | |
| 900 There are, | |
| 901 however, | |
| 902 a large number of compile-time options which may vary from site to site, | |
| 903 so an automated configuration method was needed. | |
| 904 | |
| 905 \tagdiagram{9}{Sample \MH/ Configuration File}{mhconfig} | |
| 906 The \MH/-installer must create a configuration file, | |
| 907 which contains a list of the compile-time options | |
| 908 and the values which are desired for them. | |
| 909 Compile-time options include the installation location for \MH/, | |
| 910 what kind of message transport system is to be used, | |
| 911 and the default editor for the installation. | |
| 912 An example of such a configuration file is shown in Figure~\mhconfig. | |
| 913 | |
| 914 After creating this file (several examples are included in the distribution), | |
| 915 the installer runs the \pgm{mhconfig} program, | |
| 916 which customizes the \file{Makefile\/}s and some of the programs, | |
| 917 for that site's particular installation. | |
| 918 No hand-editing of any source code should be necessary, | |
| 919 under normal circumstances. | |
| 920 | |
| 921 \subsection{Interface to the Message Transport System} % jlr & mtr | |
| 922 \MH/ will run with a number of message transport systems, | |
| 923 including \SendMail/, \MMDFII/, and a small stand-alone system. | |
| 924 One flexible method of posting mail is through an SMTP connection. | |
| 925 There are a couple of major wins in using this configuration: | |
| 926 First, | |
| 927 none of the \MH/ programs need to know where the interface programs to | |
| 928 the message transport system are located, | |
| 929 which makes them easier to move between systems. | |
| 930 Second, | |
| 931 mail can be posted on relay hosts, | |
| 932 and the local host of an \MH/ user may not need a message transport system at | |
| 933 all (as alluded to in the preceeding discussion on the POP). | |
| 934 | |
| 935 \tagdiagram{10}{Sample MTS Tailor File}{mtstailor} | |
| 936 Those parts of \MH/ which interact with the local message transport agent | |
| 937 read additional tailoring information when they start.% | |
| 938 \nfootnote{This simple facility is based on a more extensive | |
| 939 tailoring capability found in \MMDFII/.} | |
| 940 This information includes | |
| 941 the location of standard and alternate maildrops, | |
| 942 maildrop delimiter strings, | |
| 943 the locking directory and locking style, | |
| 944 and other tailoring information specific for the particular | |
| 945 message transport system in use | |
| 946 (e.g., the default server search-list when mail is posted with the SMTP). | |
| 947 In most cases, | |
| 948 by using a tailor file, | |
| 949 each site running a similar \MH/ configuration is able to simply transfer | |
| 950 \MH/ binaries between hosts. | |
| 951 An example of such a tailor file is shown in Figure~\mtstailor. | |
| 952 | |
| 953 A continuing question which is often raised is how intelligent should user | |
| 954 agents (like \MH/ and UCB \pgm{Mail}\/) be with respect to the environment in | |
| 955 which they operate. | |
| 956 At present, \MH/ likes to determine | |
| 957 the official hostnames for addresses when posting mail. | |
| 958 Many argue that this is improper or unnecessary behavior for a user agent, | |
| 959 and that the local message transport agent should handle these functions. | |
| 960 Unfortunately, | |
| 961 this implies that the message transport agent should munge headers when mail | |
| 962 is posted to remove local host aliases and only permit address fields with | |
| 963 fully-qualified addresses. | |
| 964 Sadly, neither \SendMail/ nor \MMDFII/ really gets this right | |
| 965 (flames to \file{/dev/null} please). | |
| 966 The current \MH/ maintainers believe that the resolution of host aliases to | |
| 967 official names should be a well-supported interface with the local message | |
| 968 transport agent. | |
| 969 However, to provide equal time to those who hold opposite views, | |
| 970 \MH/ supports a configuration option called \eg{DUMB} which disables \MH/'s | |
| 971 attempts to resolve addresses into fully-qualified strings. | |
| 972 | |
| 973 \section{Concluding Remarks} % jlr and mtr | |
| 974 While \MH/ has undergone significant development since | |
| 975 the original | |
| 976 Rand release, the authors have | |
| 977 tried to keep the fundamental concepts of | |
| 978 \MH/ unchanged. | |
| 979 % specific vs. general | |
| 980 The authors have continually had to battle against | |
| 981 well-meaning \MH/ users who wanted to make \MH/ | |
| 982 more like other (less powerful) user agents. | |
| 983 More and more ``features'' were often suggested for \MH/, | |
| 984 usually at the expense of making \MH/ less general, and more specific. | |
| 985 In nearly all cases, the ``features'' which these users wanted | |
| 986 were already present in \MH/ in a slightly different form, | |
| 987 or could be realized by simply writing a short shell script. | |
| 988 A classic example is the repeated requests by one user to have \pgm{dist} | |
| 989 take a list of messages rather than a single message and distribute each one | |
| 990 of them in turn. | |
| 991 A simple shell script which called \pgm{dist} repeatedly, | |
| 992 perhaps with ``canned'' arguments so the user typed in addressing information | |
| 993 only once, would easily meet this request. | |
| 994 | |
| 995 % generality | |
| 996 A number of \MH/ comands have a large number of options. | |
| 997 When adding options, the authors have tried to make the options | |
| 998 general, while still accomodating the requests of specific users. | |
| 999 An example of a specific request which was implemented as a | |
| 1000 general feature is the \eg{Previous-Sequence} profile entry | |
| 1001 (mentioned above). | |
| 1002 If you use this profile entry, every \MH/ command is forced to write | |
| 1003 out \context/ changes, making every command somewhat slower. | |
| 1004 Since only a few users wanted this capability, it was implemented | |
| 1005 in such a way that users who didn't want it, didn't have to pay | |
| 1006 the cost of slowing down every \MH/ command. | |
| 1007 | |
| 1008 % naive user :: MH | |
| 1009 \MH/ has a powerful tailoring capability provided by the \profile/. | |
| 1010 Using profile entries, users may | |
| 1011 customize their own environment without affecting others. | |
| 1012 Novice users often take advantage of the \MH/-tailoring | |
| 1013 capabilities to try to make \MH/ work similarly to | |
| 1014 other user agents they've used. | |
| 1015 This has the advantage of allowing them to quickly begin | |
| 1016 using \MH/ to handle their mail. | |
| 1017 However, since these novice users don't take advantange of all the | |
| 1018 capabilities of \MH/, | |
| 1019 they frequently will complain about things they think can't | |
| 1020 be done with \MH/, or could be done ``better'' some other way. | |
| 1021 Fortunately, | |
| 1022 as these users become more experienced with both \MH/ and \unix/, | |
| 1023 they can modify their environment to take better advantage of | |
| 1024 all of \MH/'s capabilities. | |
| 1025 Novice \MH/ users who see features lacking | |
| 1026 are encouraged to take a better look at what \MH/ {\it can} do, | |
| 1027 instead of trying to make \MH/ into something it isn't. | |
| 1028 This may sound rather inflammatory, | |
| 1029 but it would really be a much nicer world for us all if users of software | |
| 1030 systems would read the manual prior to asking questions. | |
| 1031 | |
| 1032 % speed consideration | |
| 1033 For a moment, let's consider the evolution of one \MH/ feature which has | |
| 1034 proved itself to be very useful. | |
| 1035 As users began employing \MH/ to handle their mail, | |
| 1036 the number of messages that could be processed | |
| 1037 in a given amount of time increased greatly. | |
| 1038 As the volume of messages increased however, | |
| 1039 it became clear that some \MH/ operations were too slow, | |
| 1040 in particular the interaction with the (slow) message transport system. | |
| 1041 To overcome this problem, the \pgm{push} option | |
| 1042 was added at the \whatnow/ prompt. | |
| 1043 Originally, this option was hidden from novice users | |
| 1044 and did little more than send the message in the background: | |
| 1045 any output generated by | |
| 1046 the background \pgm{send} process would be printed | |
| 1047 asyncronously on the terminal. | |
| 1048 If a message failed posting with the message transport system, | |
| 1049 it would simply be left in the \file{draft} file. | |
| 1050 | |
| 1051 Gradually, other features were added to \pgm{push}. | |
| 1052 Since users wanted to be able to send more than one draft | |
| 1053 at a time, \pgm{push} was changed to optionally | |
| 1054 rename the draft file before posting it. | |
| 1055 (This is what the hidden \switch{unique} option does.) | |
| 1056 Having message transport system diagnostics | |
| 1057 written asyncronously on the user's terminal was annoying, | |
| 1058 so \pgm{push} was made to intercept these diagnostics, | |
| 1059 and mail the user a report containing them. | |
| 1060 Although the diagnostic report mailed back by \pgm{push} contains | |
| 1061 the name of the draft which failed, | |
| 1062 a useful added feature was the ability to have \pgm{push} | |
| 1063 include the failed draft as well. | |
| 1064 Eventually, the draft-folder mechanism was implemented to make | |
| 1065 handling multiple message drafts much easier. | |
| 1066 | |
| 1067 | |
| 1068 \subsection{TODO} % mtr | |
| 1069 There are, no doubt, a number of improvements which could be made to \MH/. | |
| 1070 At the present time, | |
| 1071 what further development should \MH/ suffer? | |
| 1072 Although not by any means inclusive, | |
| 1073 here's a list: | |
| 1074 \smallskip | |
| 1075 {\advance\leftskip by\parindent | |
| 1076 \item{1.} Performance Enhancements\hbreak | |
| 1077 Hardware gets faster all the time, but people always complain that software | |
| 1078 is too slow. | |
| 1079 Owing to its user interface style, | |
| 1080 \MH/ is somewhat slower than monolithic programs like UCB \pgm{Mail}. | |
| 1081 It would be nice if \MH/ could be tuned or accelerated somehow. | |
| 1082 | |
| 1083 \item{2.} Port to System~5\hbreak | |
| 1084 \MH/ runs on 4.2\bsd/~\unix/ and Version~7 variants. | |
| 1085 It should not be difficult to port \MH/ to a SYS5 environment. | |
| 1086 This should significantly increase the number of hosts | |
| 1087 on which \MH/ can run. | |
| 1088 The authors, | |
| 1089 lacking a SYS5 machine (and experience with SYS5) to perform the port, | |
| 1090 are actively seeking a System~5 guru to attempt this feat. | |
| 1091 | |
| 1092 \item{3.} Interface to the Network News\hbreak | |
| 1093 Not all sites that run \MH/ are in the ARPA Internet, | |
| 1094 and as such the UCI BBoards facility may not be of much use to them. | |
| 1095 A good \MH/ interface to the network news would allow users on hosts with a | |
| 1096 news feed to employ the same interface for reading and sending both mail and | |
| 1097 news. | |
| 1098 | |
| 1099 \item{4.} Programmed Instruction for Beginners\hbreak | |
| 1100 The complexity of \MH/ is often intimidating to new users. | |
| 1101 It would be nice to develop a set of \pgm{learn} lessons for those users who | |
| 1102 don't like \pgm{man} pages and non-interactive tutorials. | |
| 1103 | |
| 1104 \item{5.} Message List Expansion\hbreak | |
| 1105 At present, when a list of messages is given to an \MH/ command, | |
| 1106 it expands the list and processes each message in numerical order | |
| 1107 rather than the order in which the messages were given | |
| 1108 (e.g., \eg{show\ 2\ 1} \pgm{show\/}s message~1 | |
| 1109 and then message~2). | |
| 1110 It would be nice if \MH/ processed messages in the order | |
| 1111 they were given. | |
| 1112 | |
| 1113 \item{6.} Context Changes\hbreak | |
| 1114 In nearly all cases, | |
| 1115 an \MH/ command does not write out context changes until it is about to exit | |
| 1116 successfully. | |
| 1117 There is some controversy as to whether this is the correct behavior | |
| 1118 in all cases. | |
| 1119 Some argue that once an \MH/ command has fully parsed its argument list, | |
| 1120 the context should be updated. | |
| 1121 \par} |