docs/master
changeset 117:97369a93ef39
Corrections by Kate. Again of high quality. :-)
author | markus schnalke <meillo@marmaro.de> |
---|---|
date | Mon, 25 Jun 2012 22:27:38 +0200 |
parents | 4fbd14dc5e91 |
children | 48e28eaee6f9 |
files | intro.roff |
diffstat | 1 files changed, 44 insertions(+), 37 deletions(-) [+] |
line diff
1.1 --- a/intro.roff Mon Jun 25 20:48:36 2012 +0200 1.2 +++ b/intro.roff Mon Jun 25 22:27:38 2012 +0200 1.3 @@ -51,7 +51,7 @@ 1.4 RFCs. In the advent of MIME, MH was the first implementation of this new 1.5 email standard. 1.6 .P 1.7 -In the nineties, the Internet had become popular and in December 1996, 1.8 +In the nineties, the Internet became popular and in December 1996, 1.9 Richard Coleman initiated the ``New Mail Handler'' (nmh) project. 1.10 Nmh is a fork of MH 6.8.3 and bases strongly on the 1.11 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres. 1.12 @@ -64,7 +64,7 @@ 1.13 Some systems might still provide old MH, but mainly for historical reasons. 1.14 .P 1.15 In the last years, the work on nmh was mostly maintenance work. 1.16 -However, development was revived in December 2011 1.17 +However, the development was revived in December 2011 1.18 and stayed busy since then. 1.19 1.20 .U2 "Concepts 1.21 @@ -307,44 +307,52 @@ 1.22 easily be tried out without the need to discuss changes beforehand. 1.23 In fact, revolutionary changes are hardly possible otherwise. 1.24 .P 1.25 -The mmh project implements and demonstrates the listed ideas 1.26 +The mmh project provides the basis on which the aforementioned 1.27 +ideas can be implemented and demonstrated, 1.28 without the need to change nmh or its community. 1.29 Of course, the results of the mmh project shall improve nmh, in the end. 1.30 +By no means is my intend to work against the nmh project. 1.31 + 1.32 1.33 .U2 "Target Field 1.34 .P 1.35 Any effort needs to be targeted towards a specific goal 1.36 in order to be successful. 1.37 -Following is a description of the imagined typical mmh user. 1.38 -mmh should satisfy his needs. 1.39 +Following is a description of imagined typical mmh users. 1.40 +Mmh should satisfy their needs. 1.41 .\" XXX Remove the next sentence? 1.42 Actually, as mmh is my personal version of MH, this is a description 1.43 of myself. 1.44 .P 1.45 -The target user of mmh likes Unix and its philosophy. 1.46 -He likes to use programs that are conceptionally appealing. 1.47 -He's familiar with the command line and enjoys its power. 1.48 -He is at least capable of shell scripting and wants to improve his 1.49 +The target users of mmh like Unix and its philosophy. 1.50 +They appreciate to use programs that are conceptionally appealing. 1.51 +They are familiar with the command line and enjoy its power. 1.52 +They are at least capable of shell scripting and want to improve their 1.53 productivity by scripting the mail system. 1.54 -He naturally uses modern email features, like attachments, 1.55 +.\" XXX Naturally, he uses ... 1.56 +They naturally use modern email features, such as attachments, 1.57 non-ASCII text, and digital cryptography. 1.58 -He is able to setup email system components besides mmh, 1.59 -and actually likes the choice to pick the ones he prefers. 1.60 -He has a reasonably modern system that complies to standards, 1.61 +They are able to setup email system components besides mmh, 1.62 +and actually like to have the choice to pick the ones they prefer. 1.63 +They have a reasonably modern operating system that complies to standards, 1.64 like POSIX and ANSI C. 1.65 .P 1.66 -The typical user invokes mmh commands directly in an interactive 1.67 -shell session, but as well, he uses them to automate mail handling tasks. 1.68 -Likely, he runs his mail setup on a server machine, to which he connects 1.69 -via ssh. He might also have local mmh installations on his workstations, 1.70 -but does rather not rely on graphical front-ends. He definitely wants 1.71 -to be flexible and thus be able to change his setup to suite his needs. 1.72 +The typical users invoke mmh commands directly in an interactive 1.73 +shell session, but they use them to automate mail handling tasks as well. 1.74 +Likely, they runs their mail setup on a server machine, 1.75 +to which they connect via ssh. 1.76 +They might also have local mmh installations on their workstations, 1.77 +where they tend to work with mmh directly in the shell instead 1.78 +of using graphical front-ends. 1.79 +They definitely want to be flexible and thus be able to change 1.80 +their setup to suit their needs. 1.81 .P 1.82 -The typical mmh user is a programmer himself. 1.83 -He likes to, occasionally, take the opportunity of Free Software to put 1.84 -hands on and get involved in the software he uses. 1.85 -Hence, he likes small and clean code bases and he cares for code quality. 1.86 -In general, he believes that: 1.87 +.\" XXX themself vs. themselves 1.88 +Typical mmh users are programmers themselves. 1.89 +They like to, occasionally, take the opportunity of Free Software to put 1.90 +hands on and get involved in the software they use. 1.91 +Hence, they like small and clean code bases and care for code quality. 1.92 +In general, they believe that: 1.93 .BU 1.94 Elegance \(en i.e. simplicity, clarity and generality \(en 1.95 is most important. 1.96 @@ -363,32 +371,31 @@ 1.97 The general goals for the mmh project are the following: 1.98 .IP "Stream-lining 1.99 Mmh should be stripped down to its core, which is the user agent (MUA). 1.100 -The feature set should be distilled to the ones really needed, 1.101 +The feature set should be distilled to the indispensable ones, 1.102 effectively removing corner-cases. 1.103 Parts that don't add to the main task of being a conceptionally 1.104 appealing MUA should be removed. 1.105 -This includes, the mail submission and mail retrieval facilities. 1.106 +This includes the mail submission and mail retrieval facilities. 1.107 Choice should be reduced to the main options. 1.108 .IP "Modernizing 1.109 Mmh's feature set needs to become more modern. 1.110 -Better support for attachment and digital cryptography needs to be added. 1.111 -MIME support needs to be integrated deeper and more naturally. 1.112 +Better support for attachment and digital cryptography should be added. 1.113 +MIME support should to be integrated deeper and more naturally. 1.114 The modern email features need to be readily available, out-of-the-box. 1.115 -And on the other hand, 1.116 -bulletin board support and similar obsolete facilities need to be dropped 1.117 -out. 1.118 -Likewise, ancient technologies, like hardcopy terminals, should not 1.119 -be supported any further. 1.120 +On the other hand, 1.121 +bulletin board support and similar obsolete facilities can be dropped out. 1.122 +Likewise, ancient technologies such as hardcopy terminals 1.123 +need not to be supported any further. 1.124 .IP "Code style 1.125 Mmh's source code needs to be updated to modern standards. 1.126 Standardized library functions should replace non-standard versions 1.127 whenever possible. 1.128 -Code should be separated into distinct modules when possible. 1.129 +Code should be separated into distinct modules when feasible. 1.130 Time and space optimizations should to be replaced by 1.131 clear and readable code. 1.132 A uniform programming style should prevail. 1.133 .IP "Homogeneity 1.134 The available concepts need to be expanded as far as possible. 1.135 -A small set of concepts should prevail thoroughly throughout the system. 1.136 -The whole system should appear to be of-one-style. 1.137 -It should feel like being cast as one. 1.138 +A small set of concepts should recur consistently. 1.139 +The whole system should appear to be of-one-style; 1.140 +it should feel like being cast as one.