docs/unix-phil
changeset 20:578d5c84e5c0
a lot about mh (ch04)
author | meillo@marmaro.de |
---|---|
date | Fri, 26 Feb 2010 00:57:37 +0100 |
parents | d8f428cee0d1 |
children | ca929b042039 |
files | unix-phil.ms |
diffstat | 1 files changed, 145 insertions(+), 27 deletions(-) [+] |
line diff
1.1 --- a/unix-phil.ms Thu Feb 25 15:06:34 2010 +0100 1.2 +++ b/unix-phil.ms Fri Feb 26 00:57:37 2010 +0100 1.3 @@ -745,11 +745,11 @@ 1.4 .] 1.5 1.6 .NH 2 1.7 -Contrasts to similar software 1.8 +Contrasts to monolithic mail systems 1.9 .LP 1.10 All \s-1MUA\s0s are monolithic, except \s-1MH\s0. 1.11 -This might not be completely true, 1.12 -but it reflects the general situation pretty well. 1.13 +This might not be true, 1.14 +but it reflects the situation pretty well. 1.15 .PP 1.16 While monolithic \s-1MUA\s0s gather all function in one program, 1.17 \s-1MH\s0 is a toolchest of many small tools \(en one for each job. 1.18 @@ -801,56 +801,174 @@ 1.19 \f(CWrefile\fP is like \f(CWmv\fP, 1.20 and \f(CWrmm\fP is like \f(CWrm\fP. 1.21 .PP 1.22 -The most important difference to Unix' toolchest is, 1.23 -that \s-1MH\s0's tools have an own context. 1.24 The context of the Unix tools is mainly the current working directory, 1.25 the user identification, and the environment variables. 1.26 \s-1MH\s0 extends this context by two more items: 1.27 -A current mail folder, similar to the current working directory, 1.28 -is maintained; \f(CWfolder\fP provides the functionality 1.29 -of \f(CWpwd\fP and \f(CWcd\fP for it. 1.30 -A current message, relative to the current folder, is maintained. 1.31 -This enables commands like \f(CWnext\fP and \f(CWprev\fP. 1.32 +The current mail folder, similar to the current working directory, 1.33 +for which \f(CWfolder\fP provides the functionality of 1.34 +\f(CWpwd\fP and \f(CWcd\fP. 1.35 +And the current message, relative to the current mail folder, 1.36 +which enables commands like \f(CWnext\fP and \f(CWprev\fP. 1.37 In contrast to Unix' context, which is chained to the shell session, 1.38 \s-1MH\s0's context is meant to be chained to a mail account. 1.39 -Actually, the current message is a property of the mail folder. 1.40 -This is without problem as long as a mail folder belongs to one user. 1.41 -But when multiple users want to work on one mail folder simultaneously, 1.42 -it will cause problems. 1.43 -This is a legacy from a time when emailing was different. 1.44 +But actually, the current message is a property of the mail folder, 1.45 +which is mainly a legacy. 1.46 +This will cause problems when multiple users work 1.47 +in one mail folder simultaneously. 1.48 .PP 1.49 Using a monolithic program with a captive user interface 1.50 -means ``entering'' the program, using it, and ``leaving'' the program. 1.51 -Using a toolchest like \s-1MH\s0 means running programs, 1.52 +means ``entering'' the program, using it, and ``exiting'' the program. 1.53 +Using toolchests like \s-1MH\s0 means running programs, 1.54 alone or in combinition with others, even from other toolchests, 1.55 without leaving the shell. 1.56 1.57 + 1.58 .NH 2 1.59 -Gains of the design 1.60 +Discussion of the design 1.61 .LP 1.62 +The following paragraphs discuss \s-1MH\s0 in regard to the tenets 1.63 +of the Unix Philosophy Gancarz identified. 1.64 + 1.65 +.PP 1.66 +.I "``Small is beautiful'' 1.67 +and 1.68 +.I "``do one thing well'' 1.69 +are two design goals that are directly visible in \s-1MH\s0. 1.70 +Gancarz actually presents \s-1MH\s0 as example under the headline 1.71 +``Making UNIX Do One Thing Well'': 1.72 +.QP 1.73 +[\s-1MH\s0] consists of a series of programs which 1.74 +when combined give the user an enormous ability 1.75 +to manipulate electronic mail messages. 1.76 +A complex application, it shows that not only is it 1.77 +possible to build large applications from smaller 1.78 +components, but also that such designs are actually preferable. 1.79 +.[ 1.80 +%A Mike Gancarz 1.81 +%T unix-phil 1.82 +%P 125 1.83 +.] 1.84 +.LP 1.85 +The various small programs of \s-1MH\s0 were relatively easy 1.86 +to write as each of them is small, limited to one function, 1.87 +and has clear bounderies. 1.88 +For the same reasons, they are also good to maintain. 1.89 +Further more, the system can easily get extended. 1.90 +One only needs to put a new program into the toolchest. 1.91 +This was done when \s-1MIME\s0 support was added 1.92 +(e.g. \f(CWmhbuild\fP). 1.93 +Also, different programs can exist to do the basically same job 1.94 +in different ways (e.g. in nmh: \f(CWshow\fP and \f(CWmhshow\fP). 1.95 +If someone needs a mail system with some additionally 1.96 +functions that are nowhere available yet, he best takes a 1.97 +toolchest system like \s-1MH\s0 where he can add the 1.98 +functionality with little work. 1.99 + 1.100 +.PP 1.101 +.I "Data storage. 1.102 +How \s-1MH\s0 stores data was already mentioned. 1.103 +Mail folders are directories (which contain a file 1.104 +\&\f(CW.mh_sequences\fP) under the user's \s-1MH\s0 directory 1.105 +(usually \f(CW$HOME/Mail\fP). 1.106 +Mail messages are text files located in a mail folder. 1.107 +The files contain the messages as they were received. 1.108 +The messages are numbered in ascending order in each folder. 1.109 +This mailbox format is called ``\s-1MH\s0'' after the \s-1MUA\s0. 1.110 +Alternatives are \fImbox\fP and \fImaildir\fP. 1.111 +In the mbox format all messages are stored within one file. 1.112 +This was a good solution in the early days, when messages 1.113 +were only a few lines of text and were deleted soon. 1.114 +Today, when single messages often include several megabytes 1.115 +of attachments, it is a bad solution. 1.116 +Another disadvantage of the mbox format is that it is 1.117 +more difficult to write tools that work on mail messages, 1.118 +because it is always neccessary to first find and extract 1.119 +the relevant message in the mbox file. 1.120 +With \s-1MH\s0 mailboxes, each message is a self-standing item, 1.121 +by definition. 1.122 +Also, the problem of concurrent access to one mailbox is 1.123 +reduced to the problem of concurrent access to one message. 1.124 +However, the issue of the shared parts of the context, 1.125 +as mentioned above, remains. 1.126 +Maildir is generally similar to \s-1MH\s0's format, 1.127 +but modified towards guaranteed reliability. 1.128 +This involves some complexity, unfortunately. 1.129 + 1.130 +.PP 1.131 +.I "``Avoid captive user interfaces.'' 1.132 \s-1MH\s0 is perfectly suited for non-interactive use. 1.133 It offers all functions directly and without captive user interfaces. 1.134 If users want a graphical user interface, anyhow, 1.135 -they can have it with \fIxmh\fP or \fIexmh\fP. 1.136 +they can have it with \fIxmh\fP or \fIexmh\fP, too. 1.137 These are graphical frontends for the \s-1MH\s0 toolchest. 1.138 This means, all email-related work is still done by \s-1MH\s0 tools, 1.139 -but xmh issues the calls when the user clicks a button. 1.140 -Providing easy-to-use user interfaces as frontends is a good 1.141 +but the frontend issues the appropriate calls when the user 1.142 +clicks on a button. 1.143 +Providing easy-to-use user interfaces in form of frontends is a good 1.144 approach, because it does not limit the power of the backend itself. 1.145 -The frontend will anyways only be able to make a part of the 1.146 +The frontend will anyway only be able to make a subset of the 1.147 backend's power and flexibility available. 1.148 -If it is separate, then the missing parts can still be accessed 1.149 -at the backend directly. 1.150 +But if it is a separate program, 1.151 +then the missing parts can still be accessed at the backend directly. 1.152 If it is integrated, then this will hardly be possible. 1.153 -.PP 1.154 -flexibility, no redundancy, use the shell 1.155 1.156 .PP 1.157 -easy to write: see ksh-book 1.158 +.I "``Choose portability over efficiency'' 1.159 +and 1.160 +.I "``use shell scripts to increase leverage and portability'' . 1.161 +These two tenets are indirectly, but nicely, demonstrated by 1.162 +Bolsky and Korn in their book about the korn shell. 1.163 +.[ 1.164 +%T The KornShell: command and programming language 1.165 +%A Morris I. Bolsky 1.166 +%A David G. Korn 1.167 +%I Prentice Hall 1.168 +%D 1989 1.169 +%O \s-1ISBN\s0: 0-13-516972-0 1.170 +.] 1.171 +They demonstrated, in one chapter of the book, a basic implementation 1.172 +of a subset of \s-1MH\s0 in ksh scripts. 1.173 +Of course, this was just a demonstration, but a brilliant one. 1.174 +It shows how quickly one can implement such a prototype with shell scripts, 1.175 +and how readable they are. 1.176 +The implementation in the scripting language may not be very fast, 1.177 +but it can be fast enough though, and this is all that matters. 1.178 +By having the code in an interpreted language, like the shell, 1.179 +portability becomes a minor issue, if we assume the interpreter 1.180 +to be widespread. 1.181 +This demonstration also shows how easy it is to create single programs 1.182 +of a toolchest software. 1.183 +Most of the single programs comprise less than a hundred lines of 1.184 +shell code. 1.185 +Such small software is easy to write, easy to understand, 1.186 +and thus easy to maintain. 1.187 +Being a toolchest improved the possibility to only write some parts 1.188 +and though create a working result. 1.189 +Expanding the toolchest without global changes will likely be 1.190 +possible, too. 1.191 + 1.192 +.PP 1.193 +.I "``Use software leverage to your advantage'' 1.194 +and the lesser tenet 1.195 +.I "``allow the user to tailor the environment'' 1.196 +are ideally followed in the design of \s-1MH\s0. 1.197 + 1.198 +.PP 1.199 +filters: many tools provide basic FS operations (like mv, rm, ...) 1.200 +prototypes: affect dev, but MH is very matured 1.201 1.202 .NH 2 1.203 Problems 1.204 .LP 1.205 +modern emailing 1.206 +MIME 1.207 +encodings 1.208 +largest problem: different feeling 1.209 + 1.210 +.NH 2 1.211 +Summary \s-1MH\s0 1.212 +.LP 1.213 +flexibility, no redundancy, use the shell 1.214 1.215 1.216