docs/master

diff summary.roff @ 190:2443264b1745

Added sloccount graph to the summary.
author markus schnalke <meillo@marmaro.de>
date Wed, 11 Jul 2012 18:35:11 +0200
parents 22feb390ccc4
children 68980dab3236
line diff
     1.1 --- a/summary.roff	Wed Jul 11 15:53:53 2012 +0200
     1.2 +++ b/summary.roff	Wed Jul 11 18:35:11 2012 +0200
     1.3 @@ -1,12 +1,12 @@
     1.4  .H0 "Summary
     1.5  .P
     1.6  This document describes and explains my work on mmh.
     1.7 -I have streamlined the project by removing programs, facilities
     1.8 +I have streamlined the project by removing programs, facilities,
     1.9  and options that diverted from the main task of mmh, being an MUA.
    1.10  I have modernized the code base removing obsolete functions and
    1.11  activating modern features per default.
    1.12 -Furthermore, I improved the style by refactoring clumpsy code
    1.13 -and by defining or forcing clear concepts.
    1.14 +Furthermore, I have improved the style by refactoring clumpsy code
    1.15 +and by identifying and forcing clear concepts.
    1.16  All my work was motivated by Antoine de Saint Exupery's well-known
    1.17  statement:
    1.18  .[
    1.19 @@ -16,47 +16,46 @@
    1.20  It seems that perfection is attained not when there is nothing
    1.21  more to add, but when there is nothing more to remove.
    1.22  .QE
    1.23 -.P
    1.24 -In contrast to the common expectations, I have hardly added new features.
    1.25 -I regard my improvements in selecting the relevant set of existing
    1.26 -features and exploiting the concepts more thoroughly.
    1.27 +.LP
    1.28 +Against the common expectations, I hardly added new features.
    1.29 +I regard my achievement in the selection of the relevant set of existing
    1.30 +features, the choice of sensible defaults, and the extensive
    1.31 +focus on structure and concepts.
    1.32  I believe, the result is a system simpler and clearer for both
    1.33  developing and using, without lacking important functionality.
    1.34  
    1.35 +.KS
    1.36 +.in 1c
    1.37 +.so input/sloc.grap
    1.38 +.KE
    1.39 +
    1.40  
    1.41  .U2 "Outlook
    1.42  .P
    1.43 -The work done during the project is not finished. \" XXX yet?
    1.44 +The work on mmh is not finished.
    1.45  Several tasks are left to do.
    1.46  .P
    1.47 -MIME handling is the most complex part of mmh and it requires
    1.48 -general rework.
    1.49 -.\" XXX rewrite these sentences for more smoothness
    1.50 -The changes already accomplished build upon
    1.51 -the existing structure only.
    1.52 -To integrate it fully into the concepts.
    1.53 -For instance, accessing messages and accessing MIME parts of messages
    1.54 -have inherently different concepts, although a single concept should
    1.55 -cover both.
    1.56 -The sequence notation should provide a way to address MIME parts directly
    1.57 -and should be more powerful in general. \" XXX more powerful
    1.58 +MIME handling is the most complex part of mmh and the one with the
    1.59 +highest potential for improvements.
    1.60 +The changes already accomplished so far build upon the existing structure,
    1.61 +but deeper rework is necessary to integrate MIME handling consistently.
    1.62 +For instance, accessing messages and accessing their MIME parts
    1.63 +should both covered by a single approach.
    1.64 +This requires the sequence notation to provide a way to address
    1.65 +MIME parts directly.
    1.66 +In general, the sequence notation should become more powerful.
    1.67  For instance, it is currently not possible to access the second last
    1.68  message in a given sequence.
    1.69 -Also, displaying messages with
    1.70 -.Pn show
    1.71 -requires further rework.
    1.72 +Furthermore, displaying messages can be improved.
    1.73  Encrypted messages should be decoded automatically
    1.74 -and digital signatures should be verified on-the-fly.
    1.75 -The whole task should be aligned with the common behavior of other
    1.76 -mail clients.
    1.77 -MH's unique features should not be lost, but the default should become
    1.78 -less surprising.
    1.79 -Transfer-decoding of the quoted text in replies and encoding of non-ASCII
    1.80 -characters in message header fields like
    1.81 -.Hd Subject
    1.82 -remain unsolved.
    1.83 +and digital signatures verified on-the-fly.
    1.84 +In this rework, MH's unique features need to be preserved,
    1.85 +but as well the default behavior should become less surprising.
    1.86 +Still, encoding and decoding is not done everywhere it is necessary.
    1.87 +The problems of not decoded quotations of the original message in replies
    1.88 +and not encoded non-ASCII characters in the message header remain.
    1.89  .P
    1.90 -Some of mmh's tools were hardly touched during my work.
    1.91 +Some of mmh's tools were hardly touched, yet.
    1.92  Among them are
    1.93  .Pn dist ,
    1.94  .Pn rcvdist ,
    1.95 @@ -64,31 +63,26 @@
    1.96  .Pn pick ,
    1.97  and
    1.98  .Pn sortm .
    1.99 +They should be refactored as well.
   1.100  Related to
   1.101 -.Pn sortm ,
   1.102 -a threaded message view is completely missing in mmh, so far.
   1.103 +.Pn sortm
   1.104 +is the threaded message view, which is completely missing, so far.
   1.105  .Pn pick
   1.106 -could be enhanced by message indexing.
   1.107 +could profit from message indexing.
   1.108  These fields deserve further research.
   1.109  .P
   1.110 -The features most often asked for are Maildir and IMAP support.
   1.111 +Nmh's testing framework has not been updated for mmh, yet.
   1.112 +All refactoring had been done without the safety net of a test framework.
   1.113 +Hence, experience warns that there may be subtle bugs in the code base.
   1.114 +.P
   1.115 +The features most often asked for are IMAP and Maildir support.
   1.116  But, both of them collide with MH in the same fundamental way as
   1.117 -different filesystem approaches would collide with Unix.
   1.118 -Nevertheless, an abstraction layer could provide a mapping from such
   1.119 -storage back-ends to the MH storage format.
   1.120 -Or the mmh tool chest could be reworked to operate on a generic back-end,
   1.121 +different filesystem approaches collide with Unix.
   1.122 +Nevertheless, an abstraction layer could provide a mapping between such
   1.123 +storage back-ends and the MH storage format.
   1.124 +Or, the mmh tool chest could be reworked to operate on a generic back-end,
   1.125  making the MH storage format only one of many possible back-ends.
   1.126  Research in this area is highly appreciated.
   1.127 -.\" XXX targeting the right problems?!
   1.128 -.P
   1.129 -Nmh has a testing framework that supported the developers by detecting
   1.130 -several subtle bugs.
   1.131 -All refactoring in mmh had been done without the safety net of a test
   1.132 -framework.
   1.133 -Hence, experience warns that the probability for subtle bugs lurking
   1.134 -in the code base is high.
   1.135 -Nmh's test framework should be adjusted to mmh and extended.
   1.136 -.\" XXX path notation; signing and encrypting
   1.137  
   1.138  
   1.139  .U2 "Relationship to nmh