--- a/ch01.roff	Fri May 18 11:21:51 2012 +0200
+++ b/ch01.roff	Sat May 19 17:26:15 2012 +0200
@@ -313,6 +313,8 @@
 in order to be successful.
 Following is a description of the imagined typical mmh user.
 mmh should satisfy his needs.
+Actually, as mmh is my personal version of MH, this is a description
+of myself.
 .P
 The target user of mmh likes Unix and its philosophy.
 He likes to use programs that are conceptionally appealing.
@@ -326,54 +328,61 @@
 He has a reasonably modern system that complies to standards,
 like POSIX and ANSI C.
 .P
-XXX common scenarios?
+The typical user invokes mmh commands directly in an interactive
+shell session, but as well, he uses them to automate mail handling tasks.
+Likely, he runs his mail setup on a server machine, to which he connects
+via ssh. He might also have local mmh installations on his workstations,
+but does rather not rely on graphical frontends. He definitely wants
+to be flexible and thus be able to change his setup to suite his needs.
 .P
-General assumptions of the project are:
+The typical mmh user is a programmer himself.
+He likes to, occasionally, take the opportunity of Free Software to put
+hands on and get involved in the software he uses.
+Hence, he likes small and clean code bases and he cares for code quality.
+In general, he believes that:
 .BU
-Elegance \(en being simplicity, clarity and generality \(en is most important.
+Elegance \(en i.e. simplicity, clarity and generality \(en
+is most important.
 .BU
-Concepts are more important than concrete implementations.
+Concepts are more important than the concrete implementation.
 .BU
-Time and space optimizations are only useful if absolutely needed to make
-the software usable.
+Code optimizations for anything but readability should be avoided
+if possible.
 .BU
 Having a lot of choice is bad.
+.BU
+Removed code is debugged code.
 
-.U2 "Work to do
+.U2 "Goals
 .P
 The general goals for the mmh project are the following:
-.BU
-mmh should be perfectly suited for modern emailing, out-of-the-box.
-This is a necessity to spread among new users.
-.BU
-The system shall be of-one-style. It should feel like cast as one.
-.P
-To do list:
-.BU
-Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
-task. Mail shall enter mmh's mail storage via the system mail drop
-and it shall leave mmh via the local \fLsendmail\fP command.
-.BU
-Remove any further functions that are not related to mmh's main task.
-Bulletin board support is on example. Also remove support for ancient 
-technologies, like hardcopy terminals.
-.BU
-Refactor the source code to meet modern style criteria. Use
-standardized library functions when possible.
-.BU
-Replace performance optimizations by clear and readable code.
-.BU
-Reduce the feature set to the commonly used one, removing
-corner-cases. Set sane default values.
-.BU
-Add better attachment support. Add support for digital signatures and
-encryption.
-.BU
-Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
-Integrate MIME support deeper and more natural into MH.
-.BU
-Provide a ready-to-use setup out-of-the-box.
-
-.U2 "Methods
-.P
-foo
+.IP "Stream-lining
+Mmh should be stripped down to its core, which is the MUA part of emailing.
+The feature set should be distilled to the ones really needed,
+effectively removing corner-cases.
+Functions that are not related to the main task should be removed.
+This includes, the MTA and MRA facilities.
+Choice should be reduced to the main options.
+.IP "Modernizing
+Mmh's feature set needs to become more modern.
+Better support for attachment and digital cryptography needs to be added.
+MIME support needs to be integrated deeper and more naturally.
+The modern email features need to be readily available, out-of-the-box.
+And on the other hand,
+bulletin board support and similar obsolete facilities need to be dropped
+out.
+Likewise, ancient technologies, like hardcopy terminals, should not
+be supported any further.
+.IP "Code style
+Mmh's source code needs to be updated to modern standards.
+Standardized library functions should replace non-standard versions
+whenever possible.
+Code should be separated into distinct modules when possible.
+Time and space optimizations should to be replaced by
+clear and readable code.
+A uniform programming style should prevail.
+.IP "Homogenity
+The available concepts need to be expanded as far as possible.
+A small set of concepts should prevail thoroughly throughout the system.
+The whole system should appear to be of-one-style.
+It should feel like being cast as one.