.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 a MUA.
I have modernized the code base removing obsolete functions and
activating modern features per default.
Further more, I improved the style by refactoring clumpsy code
and by defining or exploiting clear concepts.
All my work was motivated by Antoine de Saint Exupery's well-known
statement:
.[
antoine de saint exupery: Wind, Sand and Stars (1939)
.]
.QS
It seems that perfection is attained not when there is nothing
more to add, but when there is nothing more to remove.
.QE
.P
In contrast to the common expectations, I have hardly added new features.
I regard my improvements in selecting the relevant set of existing
features and exploiting the concepts more thoroughly.
I believe, the result is a system simpler and clearer for both
developing and using, without lacking important functionality.


.U2 "Outlook
.P
The work done during the project is not finished.
Several tasks are left to do.
.P
MIME handling is the most complex part of mmh and it requires
general rework.
The changes already done to it build upon the existing structure.
Yet, MIME support is not truly integrated.
For instance, accessing messages and accessing MIME parts of messages
have inherently different concepts, although a single concept should
cover both.
The sequence notation should provide a way to address MIME parts directly.
Furthermore, the sequence notation should be made more powerful in general.
For instance, it is currently not possible to access the second last
message in a given sequence.
Displaying messages with
.Pn show
requires further rework.
Encrypted messages, for example, should be decoded automatically
and digital signatures should be verified on-the-fly.
The whole task should be aligned with the common behavior of other
mail clients.
MH's unique features should not be lost, but the default should become
less surprising.
Transfer-decoding of the quoted text in replys and encoding of non-ASCII
characters in message header fields like
.Hd Subject
remain unsolved.
.P
Some of mmh's tools were hardly touched during my work.
Among them are
.Pn dist ,
.Pn rcvdist ,
.Pn mark ,
.Pn pick ,
and
.Pn sortm .
Related to
.Pn sortm ,
a threaded message view is completely missing to mmh, yet.
.Pn pick
could be enhanced by message indexing.
These fields are worthwhile for research.
.P
The features most often asked for are Maildir and IMAP support.
Yet, both of them collide with MH in the same fundamental way as
different filesystem approaches would collide with Unix.
Nevertheless, an abstraction layer could provide a mapping from such
storage back-ends to 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.
.\" XXX targeting the right problems?!
.P
Nmh has a testing framework that supported the developers by detecting
several subtle bugs.
All refactoring in mmh had been done without the safety net of a test
framework.
Hence, experience warns that the probability for subtle bugs lurking
in the code base is high.
Nmh's test framework should be adjusted to mmh and extended.
.\" XXX path notation; signing and encrypting


.U2 "Relationship to nmh
.P
The mmh project started as an experimental version of nmh because the
nmh community did not welcome my changes in the mainline version.
To not slow my work down by the need to convince the community in
discussions for each step I liked to take,
I started to create an experimental version to convicce by demonstration
of the result.
.\" behind closed doors; talks I've given
My worked on mmh was independent of the nmh community.
This enabled me to follow my vision straightly and thus produce
a result of greater pureness.
.P
Mmh shall be considered an inspiration for the future development of nmh.
It shall show identify weak part of nmh and suggest possible
improvements by change.
It shall present a lean appearance that is simpler to understand
and work with for developers and users.
By all means shall my work on mmh improve nmh in some way.
Improving nmh directly in the way I wanted was impossible for me
due to personal and community-related circumstances.
The mmh project is my way to offer my gifts though.
.P
During my work on mmh, the community of nmh suddenly became very active.
They have worked on nmh in parallel to my work on mmh.
There was no collaberation in our work, except that I have pulled some
changes from nmh to mmh.
Our work was motivated partly by similar and partly by different aims.
Although some changes are common among both projects,
fundamental differences exist.
My experimental version thus more and more felt like being a fork.
I am undecided how I like to have it.
Yet, I am strongly convinced that most of the decisions taken in mmh
were good to achieve my goals and I like to push the project even
farther in this direction.


.U2 "Weaknesses of My Work
.P
not targeting on the right problems (maildir, imap)

.P
refactoring requires testing, automated testing

.P
communication with nmh.
worked behind closed doors, but no:
talks I've given

.P
focus on myself.
But: If good for me then also good for others.