docs/master

changeset 43:c21ff903c71c

New text on mmh in Intro.
author markus schnalke <meillo@marmaro.de>
date Wed, 16 May 2012 20:23:34 +0200
parents af8c46461924
children 18e56d609fbf
files ch01.roff
diffstat 1 files changed, 61 insertions(+), 18 deletions(-) [+]
line diff
     1.1 --- a/ch01.roff	Wed May 16 17:40:34 2012 +0200
     1.2 +++ b/ch01.roff	Wed May 16 20:23:34 2012 +0200
     1.3 @@ -234,7 +234,7 @@
     1.4  Hence, while I was working on mmh, the community was working on nmh,
     1.5  in parallel.
     1.6  
     1.7 -.U2 "Naming
     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 @@ -266,34 +266,75 @@
    1.13  
    1.14  .U2 "Motivation
    1.15  .P
    1.16 -XXX
    1.17 +The mmh project is motivated by deficites of nmh and
    1.18 +my wish for general changes, combined
    1.19 +with the nmh community's reluctancy to change.
    1.20 +.P
    1.21 +nmh hadn't adjusted to modern emailing needs well enough.
    1.22 +The default setup was completely unusable for modern emailing.
    1.23 +Too much setup work was required.
    1.24 +Several modern features were already available but the community
    1.25 +didn't wanted to have them as default.
    1.26 +.P
    1.27 +In my eyes, the concepts could be exploited even better and
    1.28 +the style of the tools could be improved. Both would would simplify
    1.29 +and generalize the system, providing cleaner interfaces and more
    1.30 +software leverage, at the same time.
    1.31 +.P
    1.32 +In providing several parts of an email system, nmh would hardly
    1.33 +be able to compete with the large specialized projects that focus
    1.34 +on only one of the components. Concentrating all development power
    1.35 +on the most unique part of nmh and giving the user the choice to
    1.36 +pick his prefered set of the other mail components would be the better
    1.37 +approach in my eyes.
    1.38 +Today's pre-packaged software components encourage this approach.
    1.39  
    1.40  .U2 "Why it is worth it
    1.41  .P
    1.42 -XXX
    1.43 -XXX comparision to monolithic mail systems.
    1.44 -XXX Differenciation of MUA and mail system.
    1.45 +MH is the most important of very few command line toolchest email systems.
    1.46 +(There's also \fIim\fP by Tatsuya Kinoshita,
    1.47 +which operates on an MH mail storage.)
    1.48 +Toolchests are powerful because they can be perfectly automated and
    1.49 +extended. Toolchests are good back-ends for various sorts of front-ends.
    1.50 +They allow multiple front-ends for different special needs
    1.51 +to be implemented quickly and withough internal knowledge on emailing.
    1.52 +Further more, toolchests are much better to maintain than large monolithic
    1.53 +programs.
    1.54 +As there are few toolchests for emailing and MH-like ones are the most
    1.55 +popular amoung them, they should be developed further to keep their
    1.56 +conceptional elegance and unique scripting qualities available to users.
    1.57 +mmh will create a modern and convenient entry point for new, interested
    1.58 +users to MH-like systems.
    1.59 +.P
    1.60 +It's worthwhile to fork nmh for the development of mmh, because
    1.61 +the two projects focus on different goals and differ in fundamental questions.
    1.62 +The nmh community's reluctance to change conflicts
    1.63 +with my strong will to change.
    1.64 +In developing a separate experimental version new approaches can
    1.65 +easily be tried out without the need to discuss changes beforehand.
    1.66 +In fact, revolutionary changes are hardly possible otherwise.
    1.67 +By forking nmh, mmh will likelier bring fresh air into the field of
    1.68 +MH-like mail systems than without forking.
    1.69 +Fresh air is good to reactivate a matured project.
    1.70 +.P
    1.71 +These reasons support the decision to start mmh as a fork of nmh.
    1.72 +Of course, the results of the mmh project shall improve nmh, in the end.
    1.73  
    1.74  .U2 "Target Field
    1.75  .P
    1.76 -XXX Target field and scenarios
    1.77 -.P
    1.78 -The target user in mind likes Unix and its philosophy.
    1.79 +The target user of mmh likes Unix and its philosophy.
    1.80  He likes to use programs that are conceptionally appealing.
    1.81  He's familiar with the command line and enjoys its power.
    1.82  He is at least capable of shell scripting and wants to improve his
    1.83  productivity by scripting the mail system.
    1.84 -His computer and operating system are from post-ANSI C times.
    1.85 -He likes to attach files, exchanges text containing non-ASCII
    1.86 -characters, signs or encrypts his messages.
    1.87 -He does not use bulletin boards anymore, nor non-mbox style mail
    1.88 -drops, nor does he rely on compatibility to nmh.
    1.89 -He already has and MTA/MSA and MRA running or is able to set them
    1.90 -up.
    1.91 -He does not want to have to read a book in order to make his MUA
    1.92 -usable.
    1.93 +He naturally uses modern email features, like attachments,
    1.94 +non-ASCII text, and digital cryptrography.
    1.95 +He is able to setup email system components besides mmh,
    1.96 +and actually likes the choice to pick the ones he preferes.
    1.97 +He has a reasonably modern system that complies to standards,
    1.98 +like POSIX and ANSI C.
    1.99  .P
   1.100 -XXX Limitations
   1.101 +XXX common scenarios?
   1.102  
   1.103  .U2 "The Vision
   1.104  .P
   1.105 @@ -345,3 +386,5 @@
   1.106  .U2 "Methods
   1.107  .P
   1.108  foo
   1.109 +mmh wants to provide a ready-to-use setup for modern emailing,
   1.110 +which is a necessity to spread among new users.