docs/master
diff summary.roff @ 162:5520bbde3767
Renamed Chapter 3 back from `Future of mmh' to `Summary'.
author | markus schnalke <meillo@marmaro.de> |
---|---|
date | Mon, 09 Jul 2012 17:41:05 +0200 |
parents | future.roff@72ef1f2e58a3 |
children | 5c01017be420 |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/summary.roff Mon Jul 09 17:41:05 2012 +0200 1.3 @@ -0,0 +1,130 @@ 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 +and options that diverted from the main task of mmh, being a MUA. 1.9 +I have modernized the code base removing obsolete functions and 1.10 +activating modern features per default. 1.11 +Further more, I improved the style by refactoring clumpsy code 1.12 +and by defining or exploiting clear concepts. 1.13 +All my work was motivated by Antoine de Saint Exupery's well-known 1.14 +statement: 1.15 +.[ 1.16 +antoine de saint exupery: Wind, Sand and Stars (1939) 1.17 +.] 1.18 +.QS 1.19 +It seems that perfection is attained not when there is nothing 1.20 +more to add, but when there is nothing more to remove. 1.21 +.QE 1.22 +.P 1.23 +In contrast to the common expectations, I have hardly added new features. 1.24 +I regard my improvements in selecting the relevant set of existing 1.25 +features and exploiting the concepts more thoroughly. 1.26 +I believe, the result is a system simpler and clearer for both 1.27 +developing and using, without lacking important functionality. 1.28 + 1.29 + 1.30 +.U2 "Work Left to Do 1.31 +.P 1.32 +The work done during the project is not finished. 1.33 +Several tasks are left to do, mainly the MIME integration. 1.34 +.P 1.35 +MIME handling is the most complex part of mmh and it requires 1.36 +general rework. 1.37 +The changes already done to it build upon the existing structure. 1.38 +Yet, MIME support is not truly integrated. 1.39 +For instance, accessing messages and accessing MIME parts of messages 1.40 +have inherently different concepts, although a single concept should 1.41 +cover both. 1.42 +The sequence notation should provide a way to address MIME parts directly. 1.43 +Furthermore, the sequence notation should be made more powerful in general. 1.44 +For instance, it is currently not possible to access the second last 1.45 +message in a given sequence. 1.46 +Displaying messages with 1.47 +.Pn show 1.48 +requires further rework. 1.49 +Encrypted messages, for example, should be decoded automatically 1.50 +and digital signatures should be verified on-the-fly. 1.51 +The whole task should be aligned with the common behavior of other 1.52 +mail clients. 1.53 +MH's unique features should not be lost, but the default should become 1.54 +less surprising. 1.55 +Transfer-decoding of the quoted text in replys and encoding of non-ASCII 1.56 +characters in message header fields like 1.57 +.Hd Subject 1.58 +remain unsolved. 1.59 +.P 1.60 +Besides MIME-related tasks, some tools were not worked on yet. 1.61 +Among them are 1.62 +.Pn dist , 1.63 +.Pn rcvdist , 1.64 +.Pn mark , 1.65 +.Pn pick , 1.66 +and 1.67 +.Pn sortm . 1.68 +Concerning 1.69 +.Pn sortm , 1.70 +a threaded message view is completely missing to mmh, yet. 1.71 +.Pn pick 1.72 +could profit from message indexing. 1.73 +No research was performed in this field. 1.74 +.P 1.75 +The features most often asked for are Maildir and IMAP support. 1.76 +Yet, both of them collide with MH in the same fundamental way as 1.77 +different filesystem approaches would collide with Unix. 1.78 +Nevertheless, a storage back-end abstraction layer could provide 1.79 +a mapping from such back-ends to the MH storage format. 1.80 +Research in this area is highly appreciated. 1.81 + 1.82 + 1.83 +.U2 "Relationship to nmh 1.84 +.P 1.85 +The mmh project started as an experimental version of nmh because the 1.86 +nmh community did not welcome my changes in the mainline version. 1.87 +To not slow my work down by the need to convince the community in 1.88 +discussions for each step I liked to take, 1.89 +I started to create an experimental version to convicce by demonstration 1.90 +of the result. 1.91 +My worked on mmh was independent of the nmh community. 1.92 +This enabled me to follow my vision straightly and thus produce 1.93 +a result of greater pureness. 1.94 +.P 1.95 +Mmh shall be considered an inspiration for the future development of nmh. 1.96 +It shall show identify weak part of nmh and suggest possible 1.97 +improvements by change. 1.98 +It shall present a lean appearance that is simpler to understand 1.99 +and work with for developers and users. 1.100 +By all means shall my work on mmh improve nmh in some way. 1.101 +Improving nmh directly in the way I wanted was impossible for me 1.102 +due to personal and community-related circumstances. 1.103 +The mmh project is my way to offer my gifts though. 1.104 +.P 1.105 +During my work on mmh, the community of nmh suddenly became very active. 1.106 +They have worked on nmh in parallel to my work on mmh. 1.107 +There was no collaberation in our work, except that I have pulled some 1.108 +changes from nmh to mmh. 1.109 +Our work was motivated partly by similar and partly by different aims. 1.110 +Although some changes are common among both projects, 1.111 +fundamental differences exist. 1.112 +My experimental version thus more and more felt like being a fork. 1.113 +I am undecided how I like to have it. 1.114 +Yet, I am strongly convinced that most of the decisions taken in mmh 1.115 +were good to achieve my goals and I like to push the project even 1.116 +farther in this direction. 1.117 + 1.118 + 1.119 +.U2 "Weaknesses of My Work 1.120 +.P 1.121 +not targeting on the right problems (maildir, imap) 1.122 + 1.123 +.P 1.124 +refactoring requires testing, automated testing 1.125 + 1.126 +.P 1.127 +communication with nmh. 1.128 +worked behind closed doors, but no: 1.129 +talks I've given 1.130 + 1.131 +.P 1.132 +focus on myself. 1.133 +But: If good for me then also good for others.