# HG changeset patch # User markus schnalke # Date 1337443040 -7200 # Node ID a446f89cc5d999b49a2c7c5726a34fc95c45b54c # Parent d3a02f5e63b3a8af46d9c1b7f8a75964e80f62b2# Parent d28ff07dfc0f2c197782e72997a2f45e817ff93a merge diff -r d3a02f5e63b3 -r a446f89cc5d9 ch01.roff --- a/ch01.roff Sat May 19 17:56:15 2012 +0200 +++ b/ch01.roff Sat May 19 17:57:20 2012 +0200 @@ -317,6 +317,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. @@ -330,54 +332,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.