# HG changeset patch # User markus schnalke # Date 1337442975 -7200 # Node ID d3a02f5e63b3a8af46d9c1b7f8a75964e80f62b2 # Parent eae5e50381ce0396ec4a5c837a38815d46e88820 Various rework. diff -r eae5e50381ce -r d3a02f5e63b3 ch01.roff --- a/ch01.roff Fri May 18 11:21:51 2012 +0200 +++ b/ch01.roff Sat May 19 17:56:15 2012 +0200 @@ -153,66 +153,70 @@ .H1 "nmh: Code and Community .P -In order to understand the state, goals and dynamics of a project, -one needs to know its history. MH predates the Internet, -it comes from times before networking was universal, -times when emailing was small, short and simple. +In order to understand the condition, goals and dynamics of a project, +one needs to know the reasons. +MH predates the Internet, it comes from times before networking was universal, +it comes from times when emailing was small, short and simple. Then it grew, spread and adopted to the changes email went through. -The core-concepts, however, remained the same. -During the 80s 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. +Its core-concepts, however, remained the same. +During the Eighties students at UCI actively worked on MH. +They added new features and optimized the code for the then popular systems. +All this still was in times before POSIX and ANSI C. +As large parts of the code stem from this time, today's nmh source code +still contains many ancient parts. +BSD-specific code and constructs taylored for hardware of that time +are frequent. .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 had different style. -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 a homogenic -of-one-cast mail system. Still, the basic concepts hold it together. +Nmh started about a decade after the POSIX and ANSI C standards had been +established. A more modern coding style entered the code base, but still +a part of the developers came from ``the old days''. The developer +base became more diverse and thus resulted in code of different style. +Programming practices from different decades merged in the project. +As several peers added code, the system became more a conclomeration +of single tools rather than a homogenic of-one-cast mail system. +Still, the existing basic concepts held 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. +Despite the toolchest approach at the surface \(en a collection +of separate small programs \(en on the source code level +it is much more interweaved. +Several separate components were compiled into one program +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 -old 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). +Unfortunately, the clear separation on the outside appeared as being +pretty interweaved inside. .P -For backward-compatibility's sake, it is a common understanding to have the -default settings to be compatible, requiring any new feature to be -explicitely enabled. +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 old MH core. +MH's toolchest style made this easily possible and encourages +such approaches, but unfortunately, it lead to duplicated functions +and half-hearted implementation of the concepts. +.P +To provide backward-compatibility, it is a common understanding to not +change the default settings. In consequence, the user needs to activate modern features explicitely to be able to use them. -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 if nmh is seen to be a front-end or a -back-end. +This puts a burden on new users, because out-of-the-box nmh remains +in the same ancient style. +If nmh is seen to be a back-end, then this compatibility surely is important. +However, in the same go, new users have difficulties to use nmh for modern +emailing. +The small but matured community around nmh hardly needs much change +as they have their convenient setups since decades. .H1 "mmh .P -I started to work on my experimental version in Fall 2011. +I started to work on my experimental version in October 2011, +when there were no more than three commits to nmh in the previous nine months.. In December, when I announced my work on the nmh-workers mailing list, .[ nmh-workers mmh announce december .] -the activity in nmh rose heavily. +the activity in nmh rose much. Suddently the community started to move. -This movement was pushed much by Paul Vixie's ``edginess'' message. +This movement was heavily pushed by Paul Vixie's ``edginess'' comment. .[ nmh-workers vixie edginess .] @@ -225,7 +229,7 @@ (My login name is \fImeillo\fP.) The project follows my personal considerations and preferences. By calling it a personal project, I don't need to justify my decisions, -though, still I do. +though, still I like to do. This enabled me to follow my vision staightly and thus produce a result of greater pureness. This project model was inspired by the window manager \fIdwm\fP, @@ -233,20 +237,20 @@ targeted to satisfy Garbe's personal needs whenever conflicts appear. dwm had remained much more focused on its original goals, whereas its community-driven predecessor \fIwmii\fP had -grown large and lost it's leanness. +grown big and lost it's lean elegance. This should not happen to mmh. .P -Mmh can also stand for \fImodern mail handler\fP, and this is -the variant chosen as titel for this document. One main focus of the +Mmh also stands for \fImodern mail handler\fP, and this is +the variant chosen to entitel this document. One main focus of the project was to modernize nmh. Another main goal is resembled in the name \fIminimized mail handler\fP: Drop any parts that don't add -to the main task of mmh, being a MUA. +to the main task of mmh, being a conceptionally appealing MUA. .P It should also be noted that \fLstrcmp("mmh","nmh")<0\fP is true. Although mmh bases on nmh, it is likely seen as a step backward. I agree. However, this step backward actually is a step forward, -although in another direction. +although in a different direction. .H1 "This Thesis diff -r eae5e50381ce -r d3a02f5e63b3 ch03.roff --- a/ch03.roff Fri May 18 11:21:51 2012 +0200 +++ b/ch03.roff Sat May 19 17:56:15 2012 +0200 @@ -623,3 +623,16 @@ .H1 "Code style .P foo + + + +(e.g. the +user-visible access to whole messages and MIME parts are inherently +different). + +The \fIMH library\fP +.Fn libmh.a +collects a bunch of standard functions that many of the MH tools need, +like reading the profile or context files. +This doesn't hurt the separation. +