Mercurial > docs > master
view summary.roff @ 235:e58400695ae2
Added tag final version for changeset 348b92755bef
author | markus schnalke <meillo@marmaro.de> |
---|---|
date | Mon, 16 Jul 2012 11:25:04 +0200 |
parents | a1468cf505fd |
children |
line wrap: on
line source
.H0 "Summary .P This document describes and explains my work on mmh. I have streamlined the project by removing programs, facilities, and options that diverted from the main task of mmh, being an MUA. I have modernized the code base removing obsolete functions and activating modern features per default. Furthermore, I have improved the style by refactoring clumpsy code and by identifying and forcing clear concepts. All my work was motivated by Antoine de Saint Exup\[eacute]ry's well-known statement: .[ antoine de saint exupery wind sand and stars .] .QS It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove. .QE .LP Against the common expectations, I hardly added new features. I regard my achievement in the selection of the relevant set of existing features, the choice of sensible defaults, and the extensive focus on structure and concepts. I believe, the result is a system simpler and clearer for both developing and using, without lacking important functionality. .KS .in 1c .so input/sloc.grap .KE .U2 "Outlook .P MIME handling is the most complex part of mmh and the one with the highest potential for improvements. The changes already accomplished so far build upon the existing structure, but deeper rework is necessary to integrate MIME handling consistently. For instance, accessing messages and accessing their MIME parts should both covered by a single approach. This requires the sequence notation to provide a way to address MIME parts directly. In general, the sequence notation should become more powerful. For instance, it is currently not possible to access the second last message in a given sequence. Furthermore, displaying messages can be improved. Encrypted messages should be decoded automatically and digital signatures verified on-the-fly. In this rework, MH's unique features need to be preserved, but as well the default behavior should become less surprising. Still, encoding and decoding is not done everywhere it is necessary. The problems of not decoded quotations of the original message in replies and not encoded non-ASCII characters in the message header remain. .P Some of mmh's tools were hardly touched, yet. Among them are .Pn dist , .Pn rcvdist , .Pn mark , .Pn pick , and .Pn sortm . They should be refactored as well. Related to .Pn sortm is the threaded message view, which is completely missing, so far. .Pn pick could profit from message indexing. These fields deserve further research. .P Nmh's testing framework has not been updated for mmh, yet. All refactoring had been done without the safety net of a test framework. Hence, experience warns that there may be subtle bugs in the code base. As a consequence of the modularization rework (cf. Sec. .Cf modularization ), the compiler can no longer check the integrity of the interfaces when tools invoke each other. Automated testing should detect errors there. .P The features most often asked for are IMAP and Maildir support. But, both of them collide with MH in the same fundamental way as different file system approaches collide with Unix. Nevertheless, an abstraction layer could provide a mapping between such storage back-ends and the MH storage format. Or, the mmh tool chest could be reworked to operate on a generic back-end, making the MH storage format only one of many possible back-ends. Research in this area is highly appreciated. .U2 "Relationship to nmh .P The mmh project started as an experimental version of nmh because the nmh community did not welcome my plans and visions. The need to convincing the community of every change I liked to undertake would have slowed down my work too much. Hence, I created this experimental version to convince by demonstration. .P While I worked on mmh, nmh's community became very active as well. Although we both worked on the same code base, there was no collaboration. This, I must admit, was my failure because I kept my work hidden from the nmh community. The reasons are personal and community-related. I am sorry for that and I like to improve in the future. Nonetheless, I did not work behind completely closed doors. I discussed within the regional computer community and presented the project in two video-recorded lectures. .[ chaosseminar ccc ulm mmh .] .[ gpn entropia mmh .] First users appeared and provided feedback. .P Over time, I had to realize that, although nmh and mmh have much in common, the projects target different goals. I am still undecided how to handle it, but my experimental version more and more feels like being a fork. As I am strongly convinced that the path taken for the development of mmh is a good one, I like to push the project farther in this direction.