--- a/ch01.roff	Wed Mar 07 16:03:36 2012 +0100
+++ b/ch01.roff	Wed Mar 07 16:04:08 2012 +0100
@@ -2,6 +2,10 @@
 .P
 This chapter describes the background of the topics in this thesis.
 General knowledge of electronic mail is assumed.
+It explains the situation at the start of the project.
+It tries to describe from what state the project lifted of and where
+it headed to. This shall give an overview.
+
 
 .H1 "What is MH?
 .P
@@ -17,15 +21,8 @@
 It had started as a design proposal, not as an implementation, and 
 had in spirit remained so. This is similar to Unix, which much less
 is a specific software product, as it is a style of system design.
-MH is a toolchest of programs, modelled after the Unix toolchest,
-and it is a specific mail storage format, like Unix has its file system
-formats.
 
-.H2 "Concepts of MH" no
-.P
-FIXME
-
-.H2 "History of MH" no
+.H2 "History" no
 .P
 MH is an electronic mail system, originating in the RAND Corporation.
 In 1977, Norman Shapiro and Stockton Gaines had proposed the design
@@ -46,66 +43,155 @@
 (nmh), a fork of MH. He intended to modernize MH, improve its MIME
 capabilities, and this should be done openly within the Internet
 community. Today, nmh almost completely replaced the original MH.
+.P
+Three versions of MH are currently available:
+.BU
+.B "Old MH" .
+In most cases it has been replaced by nmh, but there are still systems
+that provide old MH. As nmh is old MH-compatible, there exist few reasons
+not to upgrade to new.
+The development of old MH stopped almost completely.
+.BU
+.B Nmh .
+The most widespread version of MH. Backward-compatible to old MH.
+Provides new featues, which need to be activated explicitely.
+Its development went slowly in the previous years, but had revived
+in Fall 2011.
+.BU
+.B Mmh
+A descendent of nmh. Had started as a non-compatible experimental
+version, but became de facto a fork. Tries to expand the same
+principal concepts in a more modern way. This version of MH is the
+subject of this thesis.
 
-.H1 "How the Fun Began
+.H2 "Concepts" no
+.P
+MH is a toolchest, modelled after the Unix toolchest. It consists of a
+bunch of tools, each covering one task of email handling. These programs
+operate on a common mail storage. The specific format of the mail storage
+also defines MH, like the file system structure defines Unix. It
+consists of directories (mail folders) and files (mail messages).
+Each file contains exactly one message in the format it had been
+received (i.e. transfer format). MH tools carry a state (context),
+consisting of current mail folder and current message. Messages can
+have symbolic names, like the next or last message or for some
+arbitrary group of messages. These names are called sequences.
 .P
-I have discovered nmh in XXX. I used to use mutt, like many
-command line-attracted Unix users. Nmh had convinced me conceptually
-at once. Unfortunately, setting it up to a convenient state became a
-tendious task. Learning its different model of email handling had,
-in contrast, been relatively easy. Learning to use MH if you are used
-to monolithic mail clients is like learning vi if you are used to
-modeless editors.
-Once having nmh set up, using it was joy because of its conceptional
-elegance and scripting capabilities, but on the other hand it was
-inconvenient in handling attachments, non-ASCII character encodings,
-and similar stuff. I found it wrong to require more and more scripts
-and configuration to have it act the expected way. In being a
-software developer, I wanted to improve the situation.
+New MH tools can be build out of existing ones easily. Default values to
+commands are stored on a command name-basis, making it trivial to have
+different versions of the same command with different defaults. Most
+of the configuration is stored in the user's profile. Form templates,
+e.g. for new messages or replies, are exchangeable and output is generally
+adjustable with format files.
+.P
+MH allows the user to automate almost everything and to modify amost
+any behavior. The system is scriptable and extendable.
+
+
+.H1 "Understanding of the Code and Community
 .P
-In Spring 2010, I asked on the nmh-workers mailing list for the
-possibility to have a Google Summer of Code project on nmh. Being a
-student, this appeared attractive to me. Eventually, it had not been
-possible, but the nmh community started to move. In these months
-nmh's future was discussed and I became part of a ``Does nmh need an
-MTA'' discussion. There, my opinion differed from the opinion of
-most others.
+In order to understand the state, goals and dynamics of a project,
+one needs to know its history. MH comes from a time before the
+Internet, a time before networking became universal, a time when
+emailing was small, short and simple. Then it grew, spread and
+adopted to the changes. The core-concepts, however, remained the
+same. During the XXX a small group of students at the University of
+California, actively worked on MH. They added features and optimized,
+like it is common for scientific work. This is still in pre-ANSI C
+times. The source code contains many ancient parts. Code constructs
+specific to BSD or hardware of that time are usual.
+.P
+Nmh started eight years after the ANSI C standard had been
+established. A more modern coding style entered the code base. Still
+a part of the developers come from ``the old days''. The developer
+base became more diverse and thus the code. Programming practices
+from different decades merged into the project. Different coding
+styles came together. It appears as if multiple peers added code
+parts, resulting in a conclomeration rather than an homogenic
+of-one-cast mail system. Still, the basic concepts hold it together.
+They were mostly untouched throughout the years.
 .P
-As it hadn't been possible to work on nmh in a way that would be
-accepted as part of my official studies, I needed to get my credit
-points in some other way. But half a year later I was back. Starting
-in Summer 2010, I took one semester off to travel through Latin America.
-Within this time, I needed to do practical computer work for three
-months. Richard Sandelman, an active nmh user, made it possible for
-me to work on nmh during this time. Juan Granda, from Santiago del
-Estero in Argentina, provided a computer and Internet connection.
-Within these three month, I became familiar with nmh's code base and
-its community. I learned how things work. Quickly it was obvious that
-I wouldn't succeed to improve on the non-ASCII character encoding
-problems, as this is one of the most intricate parts of the system.
-Instead I improved code as I read through it. I found minor bugs in
-the code and 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. This lead to long discussions, again. Finally,
-I understand their point of view, but it's not mine.
-At the end of my three-month project, I had became familiar with
-nmh's code base and community, I had improved both a bit, and I still
-was convinced that I wanted to go on with it.
+Although, at the surface, nmh is a toolchest, meaning a collection
+of completely modularized small programs, on the source code level,
+it is much more interweaved. Parts of the basic functions are
+collected in a MH standard library, which is good, but often
+separate functions are compiled into programs, for effiency reasons.
+This lead to intricate innards.
+The advent of MIME rose the complexity of email by a magnitude. This
+is visible in nmh. The MIME-related parts are the most complex ones.
+It's also visible that MIME support had been added on top of the
+original MH later. The MH style made this easily possible, but it
+also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
+and had not been thoroughly included into the concepts (e.g. the
+user-visible access to whole messages and MIME parts are inherently
+different).
+.P
+For compatibility's sake, it is a common understanding to have the
+default settings to be compatible, requiring any new feature to be
+explicitely enabled. This puts a burden on new users, because nmh
+out-of-the-box keeps staying in the same ancient style, where users
+usually want to have it practical for modern emailing.
+But of course, this depends on if nmh is seen to be a front-end or a
+back-end.
+
+
+.H1 "My Vision
+.P
+The general goals of the mmh project are the following:
+.BU
+I believe that mmh should be perfectly suited for modern emailing,
+out-of-the-box.
+.BU
+I care less about compatibility and more about conceptionally elegant
+approaches.
+.BU
+I care for general, clear, and simple concepts.
+.BU
+I like to create an of-one-style email system. It should feel like
+cast as one.
+.BU
+I plan to remove any optimizations that rises obscurity, unless it
+appears to be neccessary to make mmh usable at all.
 .P
-Another half a year later, I needed a topic for my master's thesis.
-Now it was clear: I wanted to work on nmh. No, not exactly nmh,
-because I had accepted that the nmh community has different goals
-than I have. The won't be much progress if generally different opinions
-lead to long discussions. After careful thought, I had decided to
-start an experimental version of nmh. I wanted to go my way and see
-where it would lead to. Time would tell if it would prove successful.
-Nmh would hardly be hurt by my work, but could profit from my
-experiences later.
-.P
-When I started to work on mmh, my experimental version, in Fall 2011,
-activity in nmh rose suddenly. While I was working on mmh, XXX were
-working on nmh. After long years of idleing, nmh was actively
-developed again. That was a good sign. My own work went in parallel
-and unrelated. Today, my experimental version became de facto a fork.
-The mail storage, however, is still compatible.
+.B "The target user in mind
+likes Unix and its philosophy.
+He likes to use programs that are conceptionally appealing.
+He's familiar with the command line and enjoys its power.
+He is at least capable of shell scripting and wants to improve his
+productivity by scripting the mail system.
+His computer and operating system are from post-ANSI C times.
+He likes to attach files, exchanges text containing non-ASCII
+characters, signs or encrypts his messages.
+He does not use bulletin boards anymore, nor non-mbox style mail
+drops, nor does he rely on compatibility to nmh.
+He already has and MTA/MSA and MRA running or is able to set them
+up.
+He does not want to have to read a book in order to make his MUA
+usable.
+
+
+.H1 "Things to do
+.BU
+Remove any MTA and MRA facilities. Mmh shall concentrate on the MUA
+task. Mail shall enter mmh's mail storage via the system mail drop
+and it shall leave mmh via the local \fLsendmail\fP command.
+.BU
+Remove any further functions that are not related to mmh's main task.
+Bulletin board support is on example. Also remove support for ancient 
+technologies, like hardcopy terminals.
+.BU
+Refactor the source code to meet modern style criteria. Use
+standardized library functions when possible.
+.BU
+Replace performance optimizations by clear and readable code.
+.BU
+Reduce the feature set to the commonly used one, removing
+corner-cases. Set sane default values.
+.BU
+Add better attachment support. Add support for digital signatures and
+encryption.
+.BU
+Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
+Integrate MIME support deeper and more natural into MH.
+.BU
+Provide a ready-to-use setup out-of-the-box.

--- a/ch02.roff	Wed Mar 07 16:03:36 2012 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,86 +0,0 @@
-.H0 "Previous Situation
-.P
-foo
-
-.H1 "Historic Background
-.P
-In order to understand the state, goals and dynamics of a project,
-you need to know its history. MH comes from a time before the
-Internet, a time before networking became universal, a time when
-emailing was small, short and simple. Then it grew, spread and
-adopted to the changes. The core-concepts, however, remained the
-same. During the XXX a small group of students at the University of
-California, actively worked on MH. They added features and optimized,
-like it is common for scientific work. This is still in pre-ANSI C
-times. The source code contains many ancient parts. Code constructs
-specific to BSD or hardware of that time are usual.
-.P
-Nmh started eight years after the ANSI C standard had been
-established. A more modern coding style entered the code base. Still
-a part of the developers come from ``the old days''. The developer
-base became more diverse and thus the code. Programming practices
-from different decades merged into the project. Different coding
-styles came together. It appears as if multiple peers added code
-parts, resulting in a conclomeration rather than an homogenic
-of-one-cast mail system. Still, the basic concepts hold it together.
-They were mostly untouched throughout the years.
-.P
-Although, at the surface, nmh is a toolchest, meaning a collection
-of completely modularized small programs, on the source code level,
-it is much more interweaved. Parts of the basic functions are
-collected in a MH standard library, which is good, but often
-separate functions are compiled into programs, for effiency reasons.
-This lead to intricate innards.
-The advent of MIME rose the complexity of email by a magnitude. This
-is visible in nmh. The MIME-related parts are the most complex ones.
-It's also visible that MIME support had been added on top of the
-original MH later. The MH style made this easily possible, but it
-also lead to duplicated functions (e.g. \f(CWshow\fP, \f(CWmhshow\fP)
-and had not been thoroughly included into the concepts (e.g. the
-user-visible access to whole messages and MIME parts are inherently
-different).
-.P
-For compatibility's sake, it is a common understanding to have the
-default settings to be compatible, requiring any new feature to be
-explicitely enabled. This puts a burden on new users, because nmh
-out-of-the-box keeps staying in the same ancient style, where users
-usually want to have it practical for modern emailing.
-But of course, this depends on if nmh is seen to be a front-end or a
-back-end.
-
-.H1 "My Vision
-.P
-The general goals of the mmh project are the following:
-.BU
-I believe that mmh should be perfectly suited for modern emailing,
-out-of-the-box.
-.BU
-I care less about compatibility and more about conceptionally elegant
-approaches.
-.BU
-I care for general, clear, and simple concepts.
-.BU
-I like to create an of-one-style email system.
-.BU
-I plan to remove any optimizations that rises obscurity, unless it
-appears to be neccessary to make mmh usable at all.
-.P
-.B "The target user in mind
-likes Unix and its philosophy.
-He likes to use programs that are conceptionally appealing.
-He's familiar with the command line and enjoys its power.
-He is at least capable of shell scripting and wants to improve his
-productivity by scripting the mail system.
-His computer and operating system are from post-ANSI C times.
-He likes to attach files, exchanges text containing non-ASCII
-characters, signs or encrypts his messages.
-He does not use bulletin boards anymore, nor non-mbox style mail
-drops, nor does he rely on compatibility to nmh.
-He already has and MTA/MSA and MRA running or is able to set them
-up.
-He does not want to have to read a book in order to make his MUA
-usable.
-
-.H1 "Things to do
-.P
-

--- a/preface.roff	Wed Mar 07 16:03:36 2012 +0100
+++ b/preface.roff	Wed Mar 07 16:04:08 2012 +0100
@@ -1,5 +1,69 @@
 .H0 "Preface" no
 
+.H1 "How the Fun Began" no
+.P
+I have discovered nmh in XXX. I used to use mutt, like many
+command line-attracted Unix users. Nmh had convinced me conceptually
+at once. Unfortunately, setting it up to a convenient state became a
+tendious task. Learning its different model of email handling had,
+in contrast, been relatively easy. Learning to use MH if you are used
+to monolithic mail clients is like learning vi if you are used to
+modeless editors.
+Once having nmh set up, using it was joy because of its conceptional
+elegance and scripting capabilities, but on the other hand it was
+inconvenient in handling attachments, non-ASCII character encodings,
+and similar stuff. I found it wrong to require more and more scripts
+and configuration to have it act the expected way. 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 have a Google Summer of Code project on nmh. Being a
+student, this appeared attractive to me. Eventually, it had not been
+possible, but the nmh community started to move. In these months
+nmh's future was discussed and I became part of a ``Does nmh need an
+MTA'' discussion. There, my opinion differed from the opinion of
+most others.
+.P
+As it hadn't been possible to work on nmh in a way that would be
+accepted as part of my official studies, I needed to get my credit
+points in some other way. But half a year later I was back. Starting
+in Summer 2010, I took one semester off to travel through Latin America.
+Within this time, I needed to do practical computer work for three
+months. Richard Sandelman, an active nmh user, made it possible for
+me to work on nmh during this time. Juan Granda, from Santiago del
+Estero in Argentina, provided a computer and Internet connection.
+Within these three month, I became familiar with nmh's code base and
+its community. I learned how things work. Quickly it was obvious that
+I wouldn't succeed to improve on the non-ASCII character encoding
+problems, as this is one of the most intricate parts of the system.
+Instead I improved code as I read through it. I found minor bugs in
+the code and 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. This lead to long discussions, again. Finally,
+I understand their point of view, but it's not mine.
+At the end of my three-month project, I had became familiar with
+nmh's code base and community, I had improved both a bit, and I still
+was convinced that I wanted to go on with it.
+.P
+Another half a year later, I needed a topic for my master's thesis.
+Now it was clear: I wanted to work on nmh. No, not exactly nmh,
+because I had accepted that the nmh community has different goals
+than I have. The won't be much progress if generally different opinions
+lead to long discussions. After careful thought, I had decided to
+start an experimental version of nmh. I wanted to go my way and see
+where it would lead to. Time would tell if it would prove successful.
+Nmh would hardly be hurt by my work, but could profit from my
+experiences later.
+.P
+When I started to work on mmh, my experimental version, in Fall 2011,
+activity in nmh rose suddenly. While I was working on mmh, XXX were
+working on nmh. After long years of idleing, nmh was actively
+developed again. That was a good sign. My own work went in parallel
+and unrelated. Today, my experimental version became de facto a fork.
+The mail storage, however, is still compatible.
+
+
 .H1 "Naming Conventions" no
 .P
 There are three different versions of MH available currently: original MH,
@@ -9,14 +73,6 @@
 (Mail Handler).
 Used for any MH-like mail systems, namely the original MH, nmh, and mmh.
 .P
-.B Nmh
-(New Mail Handler).
-Meaning the currently most widespread version of MH.
-.P
-.B Mmh
-(Modern Mail Handler, or Meillo's Mail Handler).
-A descendent of nmh. The version of MH that is covered in this thesis.
-.P
 .B "Mail client" .
 Synonym for MUA. The part of the mail software the user directly
 interacts with.
@@ -24,6 +80,12 @@
 
 .\" End or Preface. Start of the normal text.
 .\" Switch to arabic page numbers and start on a right page.
-.pn 0
-.af PN 0
-.if o .bp
+.if e \{
+.	pn 1
+.	af PN 1
+.\}
+.if o \{
+.	pn 0
+.	af PN 0
+.	bp
+.\}