docs/master
view summary.roff @ 183:4c5055a0e981
Explained `hidden switches'.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Wed, 11 Jul 2012 10:13:54 +0200 |
| parents | b59201e345e5 |
| children | 22feb390ccc4 |
line source
1 .H0 "Summary
2 .P
3 This document describes and explains my work on mmh.
4 I have streamlined the project by removing programs, facilities
5 and options that diverted from the main task of mmh, being an MUA.
6 I have modernized the code base removing obsolete functions and
7 activating modern features per default.
8 Furthermore, I improved the style by refactoring clumpsy code
9 and by defining or forcing clear concepts.
10 All my work was motivated by Antoine de Saint Exupery's well-known
11 statement:
12 .[
13 antoine de saint exupery: Wind, Sand and Stars (1939)
14 .]
15 .QS
16 It seems that perfection is attained not when there is nothing
17 more to add, but when there is nothing more to remove.
18 .QE
19 .P
20 In contrast to the common expectations, I have hardly added new features.
21 I regard my improvements in selecting the relevant set of existing
22 features and exploiting the concepts more thoroughly.
23 I believe, the result is a system simpler and clearer for both
24 developing and using, without lacking important functionality.
27 .U2 "Outlook
28 .P
29 The work done during the project is not finished.
30 Several tasks are left to do.
31 .P
32 MIME handling is the most complex part of mmh and it requires
33 general rework.
34 The changes already done to it build upon the existing structure.
35 Yet, MIME support is not truly integrated.
36 For instance, accessing messages and accessing MIME parts of messages
37 have inherently different concepts, although a single concept should
38 cover both.
39 The sequence notation should provide a way to address MIME parts directly.
40 Furthermore, the sequence notation should be made more powerful in general.
41 For instance, it is currently not possible to access the second last
42 message in a given sequence.
43 Displaying messages with
44 .Pn show
45 requires further rework.
46 Encrypted messages should, for example, be decoded automatically
47 and digital signatures should be verified on-the-fly.
48 The whole task should be aligned with the common behavior of other
49 mail clients.
50 MH's unique features should not be lost, but the default should become
51 less surprising.
52 Transfer-decoding of the quoted text in replys and encoding of non-ASCII
53 characters in message header fields like
54 .Hd Subject
55 remain unsolved.
56 .P
57 Some of mmh's tools were hardly touched during my work.
58 Among them are
59 .Pn dist ,
60 .Pn rcvdist ,
61 .Pn mark ,
62 .Pn pick ,
63 and
64 .Pn sortm .
65 Related to
66 .Pn sortm ,
67 a threaded message view is completely missing in mmh, yet.
68 .Pn pick
69 could be enhanced by message indexing.
70 These fields are worthwhile for research.
71 .P
72 The features most often asked for are Maildir and IMAP support.
73 Yet, both of them collide with MH in the same fundamental way as
74 different filesystem approaches would collide with Unix.
75 Nevertheless, an abstraction layer could provide a mapping from such
76 storage back-ends to the MH storage format.
77 Or the mmh tool chest could be reworked to operate on a generic back-end,
78 making the MH storage format only one of many possible back-ends.
79 Research in this area is highly appreciated.
80 .\" XXX targeting the right problems?!
81 .P
82 Nmh has a testing framework that supported the developers by detecting
83 several subtle bugs.
84 All refactoring in mmh had been done without the safety net of a test
85 framework.
86 Hence, experience warns that the probability for subtle bugs lurking
87 in the code base is high.
88 Nmh's test framework should be adjusted to mmh and extended.
89 .\" XXX path notation; signing and encrypting
92 .U2 "Relationship to nmh
93 .P
94 The mmh project started as an experimental version of nmh because the
95 nmh community did not welcome my changes in the mainline version.
96 To not slow down my work by the need to convince the community in
97 discussions for each step I liked to take,
98 I started to create an experimental version to convicce by demonstration
99 of the result.
100 .\" behind closed doors; talks I've given
101 My work on mmh was independent of the nmh community.
102 .\" XXX straight?
103 This enabled me to follow my vision straightforwardly and thus produce
104 a result of greater pureness.
105 .P
106 Mmh shall be considered as an inspiration for the future development of nmh.
107 It shall identify weak parts of nmh and suggest possible
108 improvements by change.
109 It shall present a lean appearance that is simpler to understand
110 and work with for developers and users.
111 By all means, my work on mmh shall improve nmh in some way.
112 Improving nmh directly in the way I wanted was impossible for me
113 due to personal and community-related circumstances.
114 The mmh project is my way to offer my gifts though.
115 .P
116 During my work on mmh, the community of nmh suddenly became very active.
117 They have worked on nmh in parallel to my work on mmh.
118 There was no collaberation in our work, except that I have pulled some
119 changes from nmh to mmh.
120 Our work was motivated partly by similar and partly by different aims.
121 Although some changes are common among both projects,
122 fundamental differences exist.
123 My experimental version thus more and more felt like being a fork.
124 I am undecided how I like to treat it.
125 .P
126 Yet, I am strongly convinced that the decisions taken for the
127 development of mmh were good ones with regard of my goals,
128 and I like to push the project farther in this direction.
131 .ig
132 .U2 "Weaknesses of My Work
133 .P
134 not targeting on the right problems (maildir, imap)
136 .P
137 refactoring requires testing, automated testing
139 .P
140 communication with nmh.
141 worked behind closed doors, but no:
142 talks I've given
144 .P
145 focus on myself.
146 But: If good for me then also good for others.
147 ..