view summary.roff @ 227:157c92fc1597

Further improvements.
author markus schnalke <meillo@marmaro.de>
date Sun, 15 Jul 2012 23:44:15 +0200
parents 2427d1dadb57
children a1468cf505fd
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 Exupery'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 filesystem 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.