docs/master

diff intro.roff @ 197:05a243dffaca

Added refs to the Preface; splitted the bib.
author markus schnalke <meillo@marmaro.de>
date Thu, 12 Jul 2012 00:39:41 +0200
parents 5360f5fdb118
children e417f510aaca
line diff
     1.1 --- a/intro.roff	Thu Jul 12 00:19:09 2012 +0200
     1.2 +++ b/intro.roff	Thu Jul 12 00:39:41 2012 +0200
     1.3 @@ -1,6 +1,7 @@
     1.4  .RN 1
     1.5 +.H0 "Introduction
     1.6 +.Id introduction
     1.7  
     1.8 -.H0 "Introduction
     1.9  .P
    1.10  MH is a set of mail handling tools with a common concept, similar to
    1.11  the Unix tool chest, which is a set of file handling tools with a common
    1.12 @@ -16,10 +17,10 @@
    1.13  
    1.14  
    1.15  .H1 "MH \(en the Mail Handler
    1.16 +.Id mh
    1.17  .P
    1.18  MH is a conceptual email system design and its concrete implementation.
    1.19  Notably, MH had started as a design proposal at RAND Corporation,
    1.20 -.\" XXX ref to rand corp.
    1.21  where the first implementation followed later.
    1.22  In spirit, MH is similar to Unix, which
    1.23  influenced the world more in being a set of system design concepts
    1.24 @@ -68,6 +69,7 @@
    1.25  However, the development was revived in December 2011
    1.26  and stayed busy since then.
    1.27  
    1.28 +
    1.29  .U2 "Concepts
    1.30  .P
    1.31  MH consists of a set of tools, each covering a specific task of
    1.32 @@ -174,7 +176,8 @@
    1.33  one needs to know the reasons behind them.
    1.34  This section explains the background.
    1.35  .P
    1.36 -MH predates the Internet; it comes from times before networking was universal,
    1.37 +MH predates the Internet;
    1.38 +it comes from times before networking was universal,
    1.39  it comes from times when emailing was small, short and simple.
    1.40  Then it grew, spread and adapted to the changes email went through.
    1.41  Its core-concepts, however, remained the same.
    1.42 @@ -235,24 +238,25 @@
    1.43  
    1.44  .H1 "mmh
    1.45  .P
    1.46 -.\" XXX which version did I ``fork''?
    1.47  I started to work on my experimental version in October 2011,
    1.48 -at a time when there had been no more than three commits to nmh
    1.49 -since the beginning of the year.
    1.50 +basing my work on nmh version \fInmh-1.3-dev\fP.
    1.51 +At that time no more than three commits were made to nmh
    1.52 +since the beginning of the year, the latest one being
    1.53 +.Ci a01a41d031c796b526329a4170eb23f0ac93b949
    1.54 +on 2011-04-13.
    1.55  In December, when I announced my work in progress on the
    1.56  nmh-workers mailing list,
    1.57  .[
    1.58  nmh-workers mmh announce December
    1.59  .]
    1.60 -nmh's community became active, too.
    1.61 +nmh's community became active, all of a sudden.
    1.62  This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
    1.63  .[
    1.64  nmh-workers vixie edginess
    1.65  .]
    1.66  After long years of stagnation, nmh became actively developed again.
    1.67 -Hence, while I was working on mmh, the community was once more working
    1.68 -on nmh, in parallel.
    1.69 -.\" XXX interaction between nmh and mmh
    1.70 +Hence, while I was working on mmh, the community was working on nmh,
    1.71 +in parallel.
    1.72  .P
    1.73  The name \fImmh\fP may stand for \fImodern mail handler\fP,
    1.74  because the project tries to modernize nmh.
    1.75 @@ -310,8 +314,9 @@
    1.76  Today's pre-packaged software components encourage this model.
    1.77  Mmh is a way to go for this approach.
    1.78  .P
    1.79 -It is worthwhile to fork nmh for the development of mmh, because
    1.80 -the two projects focus on different goals and differ in fundamental questions.
    1.81 +It is worthwhile to fork nmh for the development of mmh,
    1.82 +because the two projects focus on different goals and differ in
    1.83 +fundamental questions.
    1.84  The nmh community's reluctance regarding change conflicts
    1.85  with my strong desire for it.
    1.86  In developing a separate experimental version new approaches can
    1.87 @@ -329,53 +334,53 @@
    1.88  .P
    1.89  Any effort needs to be targeted towards a specific goal
    1.90  in order to be successful.
    1.91 -Following is a description of imagined typical mmh users.
    1.92 -Mmh should satisfy their needs.
    1.93 -.\" XXX  Remove the next sentence?
    1.94 +Therefore, a description of an imagined typical mmh user follows.
    1.95 +Mmh should satisfy his needs.
    1.96  Actually, as mmh is my personal version of MH, this is a description
    1.97  of myself.
    1.98 +Writing software for oneself is a reliable way to produce software
    1.99 +that matches the user's desires.
   1.100  .P
   1.101 -The target users of mmh like Unix and its philosophy.
   1.102 -They appreciate to use programs that are conceptionally appealing.
   1.103 -They are familiar with the command line and enjoy its power.
   1.104 -They are at least capable of shell scripting and want to improve their
   1.105 +The target user of mmh likes Unix and its philosophy.
   1.106 +He appreciates to use programs that are conceptionally appealing.
   1.107 +He is familiar with the command line and enjoys its power.
   1.108 +He is capable of shell scripting and wants to improve his
   1.109  productivity by scripting the mail system.
   1.110 -They use modern email features, such as attachments,
   1.111 +He uses modern email features, such as attachments,
   1.112  non-ASCII text, digital signatures and message encryption in a natural way.
   1.113 -They are able to setup email system components besides mmh,
   1.114 -and actually like to have the choice to pick the ones they prefer.
   1.115 -They have a reasonably modern operating system that complies to the
   1.116 +He is able to set up mail system components,
   1.117 +and like to have the choice to pick the ones he prefers.
   1.118 +He has a reasonably modern operating system that complies to the
   1.119  POSIX and ANSI C standards.
   1.120  .P
   1.121 -The typical users invoke mmh commands directly in an interactive
   1.122 -shell session, but they use them to automate mail handling tasks as well.
   1.123 -Likely, they run their mail setup on a server machine,
   1.124 -to which they connect via ssh.
   1.125 -They might also have local mmh installations on their workstations,
   1.126 -where they tend to work with mmh directly in the shell instead
   1.127 +The typical user invokes mmh commands directly in an interactive
   1.128 +shell session, but he uses them to automate mail handling tasks as well.
   1.129 +Likely, he runs his mail setup on a server machine,
   1.130 +to which he connects via ssh.
   1.131 +He might also have a local mmh installation on his workstation.
   1.132 +Still, he tend to use mmh directly in the shell instead
   1.133  of using graphical front-ends.
   1.134 -They definitely want to be flexible and thus be able to change
   1.135 -their setup to suit their needs.
   1.136 +He definitely wants to be flexible and thus be able to change
   1.137 +his setup to suit his needs.
   1.138  .P
   1.139 -.\" XXX themself vs. themselves
   1.140 -Typical mmh users are programmers themselves.
   1.141 -They like to, occasionally, take the opportunity of Free Software to put
   1.142 -hands on and get involved in the software they use.
   1.143 -Hence, they like small and clean code bases and care for code quality.
   1.144 -In general, they believe that:
   1.145 +The typical mmh user is a programmer.
   1.146 +He likes to, occasionally, take the opportunity of free software to put
   1.147 +hands on and get involved in the software he uses.
   1.148 +In consequence, he likes small and clean code bases and cares for
   1.149 +code quality.
   1.150 +In general, he believes that:
   1.151  .BU
   1.152 -Elegance \(en i.e. simplicity, clarity and generality \(en
   1.153 -is most important.
   1.154 +The elegance of source code is most important.
   1.155  .BU
   1.156 -Concepts are more important than the concrete implementation.
   1.157 +Concepts are more important than concrete implementations.
   1.158  .BU
   1.159 -Code optimizations for anything but readability should be avoided
   1.160 -if possible.
   1.161 +Code optimizations for anything but readability should be avoided.
   1.162  .BU
   1.163  Having a lot of choice is bad.
   1.164  .BU
   1.165  Removed code is debugged code.
   1.166  
   1.167 +
   1.168  .U2 "Goals
   1.169  .P
   1.170  The general goals for the mmh project are the following: