changeset 162:5520bbde3767

Renamed Chapter 3 back from `Future of mmh' to `Summary'.
author markus schnalke <meillo@marmaro.de>
date Mon, 09 Jul 2012 17:41:05 +0200
parents 72ef1f2e58a3
children 0628571d32d7
files future.roff makefile summary.roff
diffstat 3 files changed, 131 insertions(+), 131 deletions(-) [+]
line wrap: on
line diff
--- a/future.roff	Mon Jul 09 17:40:08 2012 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,130 +0,0 @@
-.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 "Work Left to Do
-.P
-The work done during the project is not finished.
-Several tasks are left to do, mainly the MIME integration.
-.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
-Besides MIME-related tasks, some tools were not worked on yet.
-Among them are
-.Pn dist ,
-.Pn rcvdist ,
-.Pn mark ,
-.Pn pick ,
-and
-.Pn sortm .
-Concerning
-.Pn sortm ,
-a threaded message view is completely missing to mmh, yet.
-.Pn pick
-could profit from message indexing.
-No research was performed in this field.
-.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, a storage back-end abstraction layer could provide
-a mapping from such back-ends to the MH storage format.
-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 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.
-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.
--- a/makefile	Mon Jul 09 17:40:08 2012 +0200
+++ b/makefile	Mon Jul 09 17:41:05 2012 +0200
@@ -1,6 +1,6 @@
 NAME = thesis
 CHAPS = style front.roff dedication.roff abstract.roff toc.roff \
-	preface.roff intro.roff discussion.roff future.roff refs.roff \
+	preface.roff intro.roff discussion.roff summary.roff refs.roff \
 	official.roff colophon.roff
 PDFFLAGS = -sPAPERSIZE=a4 -dPDFSETTINGS=/prepress
 REFER = refer -n -p bib -p rfcs -e -P -sLAD -l,2 -k
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/summary.roff	Mon Jul 09 17:41:05 2012 +0200
@@ -0,0 +1,130 @@
+.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 "Work Left to Do
+.P
+The work done during the project is not finished.
+Several tasks are left to do, mainly the MIME integration.
+.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
+Besides MIME-related tasks, some tools were not worked on yet.
+Among them are
+.Pn dist ,
+.Pn rcvdist ,
+.Pn mark ,
+.Pn pick ,
+and
+.Pn sortm .
+Concerning
+.Pn sortm ,
+a threaded message view is completely missing to mmh, yet.
+.Pn pick
+could profit from message indexing.
+No research was performed in this field.
+.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, a storage back-end abstraction layer could provide
+a mapping from such back-ends to the MH storage format.
+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 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.
+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.