1.1 --- a/ch01.roff	Wed May 16 20:42:30 2012 +0200
     1.2 +++ b/ch01.roff	Thu May 17 16:17:09 2012 +0200
     1.3 @@ -233,8 +233,6 @@
     1.4  After long years of much stagnation, nmh became actively developed again.
     1.5  Hence, while I was working on mmh, the community was working on nmh,
     1.6  in parallel.
     1.7 -
     1.8 -.U2 Naming
     1.9  .P
    1.10  The name \fImmh\fP stands for \fImeillo's mail handler\fP,
    1.11  because mmh is my own version of MH.
    1.12 @@ -264,33 +262,11 @@
    1.13  However, this step backward actually is a step forward,
    1.14  although in another direction.
    1.15  
    1.16 +
    1.17 +.H1 "This Thesis
    1.18 +
    1.19  .U2 "Motivation
    1.20  .P
    1.21 -The mmh project is motivated by deficites of nmh and
    1.22 -my wish for general changes, combined
    1.23 -with the nmh community's reluctancy to change.
    1.24 -.P
    1.25 -nmh hadn't adjusted to modern emailing needs well enough.
    1.26 -The default setup was completely unusable for modern emailing.
    1.27 -Too much setup work was required.
    1.28 -Several modern features were already available but the community
    1.29 -didn't wanted to have them as default.
    1.30 -.P
    1.31 -In my eyes, the concepts could be exploited even better and
    1.32 -the style of the tools could be improved. Both would would simplify
    1.33 -and generalize the system, providing cleaner interfaces and more
    1.34 -software leverage, at the same time.
    1.35 -.P
    1.36 -In providing several parts of an email system, nmh would hardly
    1.37 -be able to compete with the large specialized projects that focus
    1.38 -on only one of the components. Concentrating all development power
    1.39 -on the most unique part of nmh and giving the user the choice to
    1.40 -pick his prefered set of the other mail components would be the better
    1.41 -approach in my eyes.
    1.42 -Today's pre-packaged software components encourage this approach.
    1.43 -
    1.44 -.U2 "Why it is worth it
    1.45 -.P
    1.46  MH is the most important of very few command line toolchest email systems.
    1.47  (There's also \fIim\fP by Tatsuya Kinoshita,
    1.48  which operates on an MH mail storage.)
    1.49 @@ -306,6 +282,32 @@
    1.50  mmh will create a modern and convenient entry point for new, interested
    1.51  users to MH-like systems.
    1.52  .P
    1.53 +The mmh project is motivated by deficites of nmh and
    1.54 +my wish for general changes, combined
    1.55 +with the nmh community's reluctancy to change.
    1.56 +.P
    1.57 +nmh hadn't adjusted to modern emailing needs well enough.
    1.58 +The default setup was completely unusable for modern emailing.
    1.59 +Too much setup work was required.
    1.60 +Several modern features were already available but the community
    1.61 +didn't wanted to have them as default.
    1.62 +mmh is a way to change this.
    1.63 +.P
    1.64 +In my eyes, MH's concepts could be exploited even better and
    1.65 +the style of the tools could be improved. Both would simplify
    1.66 +and generalize the system, providing cleaner interfaces and more
    1.67 +software leverage, at the same time.
    1.68 +mmh is a way to demonstrate this.
    1.69 +.P
    1.70 +In providing several parts of an email system, nmh can hardly
    1.71 +compete with the large specialized projects that focus
    1.72 +on only one of the components.
    1.73 +The situation can be improved by concentrating the development power
    1.74 +on the most unique part of MH and letting the user pick his prefered
    1.75 +set of other mail components.
    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's 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  The nmh community's reluctance to change conflicts
    1.82 @@ -313,15 +315,19 @@
    1.83  In developing a separate experimental version new approaches can
    1.84  easily be tried out without the need to discuss changes beforehand.
    1.85  In fact, revolutionary changes are hardly possible otherwise.
    1.86 -By forking nmh, mmh will likelier bring fresh air into the field of
    1.87 -MH-like mail systems than without forking.
    1.88 -Fresh air is good to reactivate a matured project.
    1.89 +These reasons support the decision to start mmh as a fork of nmh.
    1.90  .P
    1.91 -These reasons support the decision to start mmh as a fork of nmh.
    1.92 +The mmh project provides the basis to implemented and demonstrated
    1.93 +the listed ideas without the need to change nmh or its community.
    1.94  Of course, the results of the mmh project shall improve nmh, in the end.
    1.95  
    1.96  .U2 "Target Field
    1.97  .P
    1.98 +Any effort needs to be targeted towards a specific goal
    1.99 +in order to be successful.
   1.100 +Following is a description of the imagined typical mmh user.
   1.101 +mmh should satisfy his needs.
   1.102 +.P
   1.103  The target user of mmh likes Unix and its philosophy.
   1.104  He likes to use programs that are conceptionally appealing.
   1.105  He's familiar with the command line and enjoys its power.
   1.106 @@ -335,26 +341,28 @@
   1.107  like POSIX and ANSI C.
   1.108  .P
   1.109  XXX common scenarios?
   1.110 -
   1.111 -.U2 "The Vision
   1.112  .P
   1.113 -The general goals of the mmh project are the following:
   1.114 +General assumptions of the project are:
   1.115  .BU
   1.116 -I believe that mmh should be perfectly suited for modern emailing,
   1.117 -out-of-the-box.
   1.118 +Elegance \(en being simplicity, clarity and generality \(en is most important.
   1.119  .BU
   1.120 -I care less about compatibility and more about conceptionally elegant
   1.121 -approaches.
   1.122 +Concepts are more important than concrete implementations.
   1.123  .BU
   1.124 -I care for general, clear, and simple concepts.
   1.125 +Time and space optimizations are only useful if absolutely needed to make
   1.126 +the software usable.
   1.127  .BU
   1.128 -I like to create an of-one-style email system. It should feel like
   1.129 -cast as one.
   1.130 -.BU
   1.131 -I plan to remove any optimizations that rises obscurity, unless it
   1.132 -appears to be neccessary to make mmh usable at all.
   1.133 +Having a lot of choice is bad.
   1.134  
   1.135  .U2 "Work to do
   1.136 +.P
   1.137 +The general goals for the mmh project are the following:
   1.138 +.BU
   1.139 +mmh should be perfectly suited for modern emailing, out-of-the-box.
   1.140 +This is a necessity to spread among new users.
   1.141 +.BU
   1.142 +The system shall be of-one-style. It should feel like cast as one.
   1.143 +.P
   1.144 +To do list:
   1.145  .BU
   1.146  Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
   1.147  task. Mail shall enter mmh's mail storage via the system mail drop
   1.148 @@ -380,11 +388,6 @@
   1.149  .BU
   1.150  Provide a ready-to-use setup out-of-the-box.
   1.151  
   1.152 -
   1.153 -.H1 "Goals of this Thesis
   1.154 -
   1.155  .U2 "Methods
   1.156  .P
   1.157  foo
   1.158 -mmh wants to provide a ready-to-use setup for modern emailing,
   1.159 -which is a necessity to spread among new users.