docs/master
view summary.roff @ 226:27c28990b844
Added quote by Steve Johnson.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 15 Jul 2012 21:57:51 +0200 |
| parents | de8172bcdc5e |
| children | a1468cf505fd |
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 have improved the style by refactoring clumpsy code
9 and by identifying and 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
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 .LP
20 Against the common expectations, I hardly added new features.
21 I regard my achievement in the selection of the relevant set of existing
22 features, the choice of sensible defaults, and the extensive
23 focus on structure and concepts.
24 I believe, the result is a system simpler and clearer for both
25 developing and using, without lacking important functionality.
27 .KS
28 .in 1c
29 .so input/sloc.grap
30 .KE
33 .U2 "Outlook
34 .P
35 MIME handling is the most complex part of mmh and the one with the
36 highest potential for improvements.
37 The changes already accomplished so far build upon the existing structure,
38 but deeper rework is necessary to integrate MIME handling consistently.
39 For instance, accessing messages and accessing their MIME parts
40 should both covered by a single approach.
41 This requires the sequence notation to provide a way to address
42 MIME parts directly.
43 In general, the sequence notation should become more powerful.
44 For instance, it is currently not possible to access the second last
45 message in a given sequence.
46 Furthermore, displaying messages can be improved.
47 Encrypted messages should be decoded automatically
48 and digital signatures verified on-the-fly.
49 In this rework, MH's unique features need to be preserved,
50 but as well the default behavior should become less surprising.
51 Still, encoding and decoding is not done everywhere it is necessary.
52 The problems of not decoded quotations of the original message in replies
53 and not encoded non-ASCII characters in the message header remain.
54 .P
55 Some of mmh's tools were hardly touched, yet.
56 Among them are
57 .Pn dist ,
58 .Pn rcvdist ,
59 .Pn mark ,
60 .Pn pick ,
61 and
62 .Pn sortm .
63 They should be refactored as well.
64 Related to
65 .Pn sortm
66 is the threaded message view, which is completely missing, so far.
67 .Pn pick
68 could profit from message indexing.
69 These fields deserve further research.
70 .P
71 Nmh's testing framework has not been updated for mmh, yet.
72 All refactoring had been done without the safety net of a test framework.
73 Hence, experience warns that there may be subtle bugs in the code base.
74 As a consequence of the modularization rework (cf. Sec.
75 .Cf modularization ),
76 the compiler can no longer check the integrity of the interfaces
77 when tools invoke each other.
78 Automated testing should detect errors there.
79 .P
80 The features most often asked for are IMAP and Maildir support.
81 But, both of them collide with MH in the same fundamental way as
82 different filesystem approaches collide with Unix.
83 Nevertheless, an abstraction layer could provide a mapping between such
84 storage back-ends and the MH storage format.
85 Or, the mmh tool chest could be reworked to operate on a generic back-end,
86 making the MH storage format only one of many possible back-ends.
87 Research in this area is highly appreciated.
90 .U2 "Relationship to nmh
91 .P
92 The mmh project started as an experimental version of nmh because the
93 nmh community did not welcome my plans and visions.
94 The need to convincing the community of every change I liked to
95 undertake would have slowed down my work too much.
96 Hence, I created this experimental version to convince by demonstration.
97 .P
98 While I worked on mmh, nmh's community became very active as well.
99 Although we both worked on the same code base, there was no collaboration.
100 This, I must admit, was my failure because I kept my work hidden
101 from the nmh community.
102 The reasons are personal and community-related.
103 I am sorry for that and I like to improve in the future.
104 Nonetheless, I did not work behind completely closed doors.
105 I discussed within the regional computer community and
106 presented the project in two video-recorded lectures.
107 .[
108 chaosseminar ccc ulm mmh
109 .]
110 .[
111 gpn entropia mmh
112 .]
113 First users appeared and provided feedback.
114 .P
115 Over time, I had to realize that, although nmh and mmh have much
116 in common, the projects target different goals.
117 I am still undecided how to handle it, but my experimental version
118 more and more feels like being a fork.
119 As I am strongly convinced that the path taken for the
120 development of mmh is a good one,
121 I like to push the project farther in this direction.