1.1 --- a/ch01.roff	Fri May 18 11:21:51 2012 +0200
     1.2 +++ b/ch01.roff	Sat May 19 17:26:15 2012 +0200
     1.3 @@ -313,6 +313,8 @@
     1.4  in order to be successful.
     1.5  Following is a description of the imagined typical mmh user.
     1.6  mmh should satisfy his needs.
     1.7 +Actually, as mmh is my personal version of MH, this is a description
     1.8 +of myself.
     1.9  .P
    1.10  The target user of mmh likes Unix and its philosophy.
    1.11  He likes to use programs that are conceptionally appealing.
    1.12 @@ -326,54 +328,61 @@
    1.13  He has a reasonably modern system that complies to standards,
    1.14  like POSIX and ANSI C.
    1.15  .P
    1.16 -XXX common scenarios?
    1.17 +The typical user invokes mmh commands directly in an interactive
    1.18 +shell session, but as well, he uses them to automate mail handling tasks.
    1.19 +Likely, he runs his mail setup on a server machine, to which he connects
    1.20 +via ssh. He might also have local mmh installations on his workstations,
    1.21 +but does rather not rely on graphical frontends. He definitely wants
    1.22 +to be flexible and thus be able to change his setup to suite his needs.
    1.23  .P
    1.24 -General assumptions of the project are:
    1.25 +The typical mmh user is a programmer himself.
    1.26 +He likes to, occasionally, take the opportunity of Free Software to put
    1.27 +hands on and get involved in the software he uses.
    1.28 +Hence, he likes small and clean code bases and he cares for code quality.
    1.29 +In general, he believes that:
    1.30  .BU
    1.31 -Elegance \(en being simplicity, clarity and generality \(en is most important.
    1.32 +Elegance \(en i.e. simplicity, clarity and generality \(en
    1.33 +is most important.
    1.34  .BU
    1.35 -Concepts are more important than concrete implementations.
    1.36 +Concepts are more important than the concrete implementation.
    1.37  .BU
    1.38 -Time and space optimizations are only useful if absolutely needed to make
    1.39 -the software usable.
    1.40 +Code optimizations for anything but readability should be avoided
    1.41 +if possible.
    1.42  .BU
    1.43  Having a lot of choice is bad.
    1.44 +.BU
    1.45 +Removed code is debugged code.
    1.46  
    1.47 -.U2 "Work to do
    1.48 +.U2 "Goals
    1.49  .P
    1.50  The general goals for the mmh project are the following:
    1.51 -.BU
    1.52 -mmh should be perfectly suited for modern emailing, out-of-the-box.
    1.53 -This is a necessity to spread among new users.
    1.54 -.BU
    1.55 -The system shall be of-one-style. It should feel like cast as one.
    1.56 -.P
    1.57 -To do list:
    1.58 -.BU
    1.59 -Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
    1.60 -task. Mail shall enter mmh's mail storage via the system mail drop
    1.61 -and it shall leave mmh via the local \fLsendmail\fP command.
    1.62 -.BU
    1.63 -Remove any further functions that are not related to mmh's main task.
    1.64 -Bulletin board support is on example. Also remove support for ancient 
    1.65 -technologies, like hardcopy terminals.
    1.66 -.BU
    1.67 -Refactor the source code to meet modern style criteria. Use
    1.68 -standardized library functions when possible.
    1.69 -.BU
    1.70 -Replace performance optimizations by clear and readable code.
    1.71 -.BU
    1.72 -Reduce the feature set to the commonly used one, removing
    1.73 -corner-cases. Set sane default values.
    1.74 -.BU
    1.75 -Add better attachment support. Add support for digital signatures and
    1.76 -encryption.
    1.77 -.BU
    1.78 -Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
    1.79 -Integrate MIME support deeper and more natural into MH.
    1.80 -.BU
    1.81 -Provide a ready-to-use setup out-of-the-box.
    1.82 -
    1.83 -.U2 "Methods
    1.84 -.P
    1.85 -foo
    1.86 +.IP "Stream-lining
    1.87 +Mmh should be stripped down to its core, which is the MUA part of emailing.
    1.88 +The feature set should be distilled to the ones really needed,
    1.89 +effectively removing corner-cases.
    1.90 +Functions that are not related to the main task should be removed.
    1.91 +This includes, the MTA and MRA facilities.
    1.92 +Choice should be reduced to the main options.
    1.93 +.IP "Modernizing
    1.94 +Mmh's feature set needs to become more modern.
    1.95 +Better support for attachment and digital cryptography needs to be added.
    1.96 +MIME support needs to be integrated deeper and more naturally.
    1.97 +The modern email features need to be readily available, out-of-the-box.
    1.98 +And on the other hand,
    1.99 +bulletin board support and similar obsolete facilities need to be dropped
   1.100 +out.
   1.101 +Likewise, ancient technologies, like hardcopy terminals, should not
   1.102 +be supported any further.
   1.103 +.IP "Code style
   1.104 +Mmh's source code needs to be updated to modern standards.
   1.105 +Standardized library functions should replace non-standard versions
   1.106 +whenever possible.
   1.107 +Code should be separated into distinct modules when possible.
   1.108 +Time and space optimizations should to be replaced by
   1.109 +clear and readable code.
   1.110 +A uniform programming style should prevail.
   1.111 +.IP "Homogenity
   1.112 +The available concepts need to be expanded as far as possible.
   1.113 +A small set of concepts should prevail thoroughly throughout the system.
   1.114 +The whole system should appear to be of-one-style.
   1.115 +It should feel like being cast as one.