.H0 "Preface" no

.P
MH is a set of mail handling tools with a common concept, like
the Unix toolchest is a set of file handling tools with a common
concept. nmh is the currently most popular implementation of an
MH-like mail handling system.
This thesis describes creating an experimental version of nmh,
named \fImmh\fP,
to modernize, stream-line and to exploit the concepts
even more thoroughly.

.U2 "The Path to this Thesis
.P
I have discovered nmh in September 2009. At that time I used to use the
mail client mutt, like many command line-attracted Unix users do.
The concepts of nmh had convinced me at once and thus learning
its different model of email handling had been relatively easy.
The change was like
managing files in the Unix shell when being used to graphical file
managers, or like learning vi when being used to modeless editors.
The transition had not been trivial but, as I was convinced by the new
concepts and
already managed my files with shell tools and edited with vi, not too
difficult neither.
In contrast, setting up nmh to a convenient state became a tendious task
that took several months.
.P
Once having nmh arranged to a convenient state, I enjoyed using it
because of its conceptional elegance and its scripting capabilities.
On the other hand, however, it still was
inconvenient in handling attachments, non-ASCII character encodings,
and similar features of modern emailing.
My setup required more and more additional configuration and helper scripts
to have nmh act the way I expected it to behave, although my
expectations were rather common for modern emailing than exceptionel.
In being a software developer, I wanted to improve the situation.
.P
In Spring 2010, I asked on the nmh-workers mailing list for the
possibility to offer a Google Summer of Code project on nmh.
Participating in the development this way appeared attractive to me,
especially as it would have been possible to have the project
accepted at university. Although the nmh community
generally had been positive on the
suggestion, eventually it had not been possible to manage the
administrative work. Though my proposal had started the nmh community
to move. In the following weeks, goals for nmh's future were discussed
on the list. During the discussions, I became involved in the
question whether nmh should be an MTA. (Thread subject:
``should nmh be an MTA or an MUA?''.)
In this point, my opinion differed from the opinion of most others
as I voted for the MTA facility of nmh to be removed.
.P
Being unable to work on nmh in a way that would be
accepted as part of my official studies, I had to pick another project.
Half a year later, starting in August 2010,
I took one semester off to travel through Latin America.
Within this time, I had to do practical computer work for three
months.
This brought me back to nmh.
Richard Sandelman, an active nmh user, made it possible for
me to work on nmh. Juan Granda, living in Santiago del
Estero in Argentina, provided a computer and Internet connection for
my work.
Within the three month, I became familiar with nmh's code base and
its community. I learned how things work. Quickly it became obvious that
I wouldn't succeed with my main goal, to improve the character
encoding handling within the project. One obvious problem is the missing
transfer decoding of the quoted text in replies.
As this is one of the most intricate parts of the system, the goal
was simply too difficult to reach.
Instead I improved the code as I read through it. I found minor bugs
for which I proposed fixes to the community. Also I
could improve the documentation. When I started with
larger code changes, I had to discover that the community's wish for
compatibility was stronger than its wish for convenient
out-of-the-box setups \(en in contrast with my opinion.
This lead to long discussions, again.
I came to understand their point of view, but it simply is not mine.
.P
At the end of my three-month project, I had become familiar with
nmh's code base and its community. I had improved the project a bit
and I still was convinced that I wanted to go on with that.
.P
Another half a year later, the end of my studies came within reach.
I needed a topic for my master's thesis.
There was no question: I wanted to work on nmh.
But well, not exactly on nmh,
because I had accepted that the nmh community has different goals
than I have. This would result in long discussions and thus few progress.
After careful thought, I decided to start an experimental version of nmh.
I wanted to follow my own ideas of how nmh should look like. I wanted
to see where that would lead to. I wanted to compare the result of my
work to the present state of nmh. Time should prove me successful or
not.
Nmh would hardly be hurt by my work as I would not interfere with
them. But nmh would profit from my experiences.

.U2 "Focus and Delimitation of the Document
.P
This document describes my work on the experimental version, named
\fImmh\fP. It explains the changes I did to nmh, with having the focus
on the reasons for the changes. It discusses technical, historical,
social and philosophical reasons. On the technical side, this document
explains how an existing project was stream-lined by exploiting the
central concepts better and removing rough edges. On the historical
side, changes in the use cases and the features of email and reactions
to them are discussed. Socially, this document describes the effects
and experiences of a newcomer with revolutionary aims entering an old
and matured software projects and its community. Finally, philosophical
thoughts on style, mainly based to the Unix philosophy, are present
throughout the discussions.
.P
This document is written for the community \(en developers and users \(en
around MH-like mail systems.
First of all, the document shall propagade the design goals and
implementation decisions of mmh. But as well, it shall clarify my
perception of the
concepts of MH and Unix, and the therefrom resulting point of view.
Further more, the document shall explain this view on nmh and mmh.
Despite the focus on MH-like systems, this document can be useful
to anyone interested in the Unix philosophy, as well as anyone
involved in old software projects, be it code-related or community-related.
.P
The reader is expected to know Unix, C and email well. Good Unix shell
knowledge, including shell scripting, is required. MH relies fundamentally
on the shell. Without the power of the shell, MH becomes a motorbike
without winding roads.
Introductions to Unix and its shell can be found in XXX.
The reader is
expected to be familiar with the C programming language, although the
document should be quite readable without knowledge of C, too.
The book by Kernighan and Ritchie is the definitive guide to C.
Some book about system-level C programming is worthwile additional
literature. Rochkind and Curry have written such books.
As large parts of the code are old, old books are likely more helpful.
The format of email messages as well as the structure of email transfer
systems should be familiar to the reader, at least on a basic level.
It's advisable to have had, at least cross-read, the RFCs 821 and 822.
The book XXX introduces email well, too.
Frequent references to the Unix philosophy will be made.
Gancarz XXX had tried to sum the philosophy up. Even better but less
concrete is the literature by Kernighan and Pike XXX.
The term paper ``Why the Unix Philosophy still matters'' by myself
provides an overview on the topic, including a case study of MH.


.U2 "Organization
.P
Which font for what use.
Meaning of `foo(1)'.
RFCs.
MH vs. nmh vs. mmh.
.P
This thesis is devided into XXX chapters, ...
.P
.I Chapter 1
introduces ...
.P
.I Chapter 2
describes ...
.P
.I Chapter 3
covers ...


.U2 "Acknowledgments
.P
To be written at the very end.


.\" End or Preface. Start of the normal text.
.\" Switch to arabic page numbers and start on a right page.
.if e \{
.	pn 1
.	af PN 1
.\}
.if o \{
.	pn 0
.	af PN 0
.	bp
.\}