docs/master: ch01.roff comparison

comparison ch01.roff @ 106:3c4e5f0a7e7b

Included (English language) corrections by Kate.

author	markus schnalke <meillo@marmaro.de>
date	Sat, 23 Jun 2012 22:08:17 +0200
parents	a782488c85f5
children

comparison

equal deleted inserted replaced

-:9ff356d84c57
+:3c4e5f0a7e7b
 MH-like mail handling system.
 This thesis describes an experimental version of nmh, named \fImmh\fP.
 .P
 This chapter introduces MH, its history, concepts and how it is used.
 It describes nmh's code base and community to give the reader
-a better understanding of the state from which mmh started off.
+a better understanding of the state of mmh when it started off.
 Further more, this chapter outlines the mmh project itself,
 describing the motivation for it and its goals.
 .H1 "MH \(en the Mail Handler
 MH follows this philosophy.
 .U2 "History
 .P
 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
-had proposed the design
+proposed the design
 of a new mail handling system, called ``Mail Handler'' (MH),
 to superseed RAND's old monolithic ``Mail System'' (MS).
 Two years later, in 1979, Bruce Borden took the proposal and implemented a
 prototype of MH.
-Before the prototype had been available, the concept was
+Before the prototype's existence, the concept was
 believed to be practically unusable.
-But the prototype had proven successful and replaced MS thereafter.
+But the prototype proved successful and replaced MS thereafter.
 In replacing MS, MH grew to an all-in-one mail system.
 .P
-In the early Eighties,
+In the early eighties,
-the University of California at Irvine (UCI) had started to use MH.
+the University of California at Irvine (UCI) started to use MH.
-Marshall T. Rose and John L. Romine became the driving force then.
+Marshall T. Rose and John L. Romine then became the driving force.
 They took over the development and pushed MH forward.
 RAND had put the code into the public domain by then.
 MH was developed at UCI at the time when the Internet appeared,
 when UCB implemented the TCP/IP stack, and when Allman wrote Sendmail.
 MH was extended as emailing became more featured.
 The development of MH was closely related to the development of email
 RFCs. In the advent of MIME, MH was the first implementation of this new
 email standard.
 .P
-In the Nineties, the Internet had become popular and in December 1996,
+In the nineties, the Internet had become popular and in December 1996,
 Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
 Nmh is a fork of MH 6.8.3 and bases strongly on the
 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
 Colman intended to modernize MH and improve its portability and
 MIME handling capabilities.
 February 1996, soon after the development of nmh had started.
 Today, nmh has almost completely replaced the original MH.
 Some systems might still provide old MH, but mainly for historical reasons.
 .P
 In the last years, the work on nmh was mostly maintenance work.
-However, the development revived in December 2011
+However, development was revived in December 2011
 and stayed busy since then.
 .U2 "Concepts
 .P
 MH consists of a set of tools, each covering a specific task of
 refiling a message to a different folder, listing the messages in a folder.
 All of the programs operate on a common mail storage.
 .P
 The mail storage consists of \fImail folders\fP (directories) and
 \fPmessages\fP (regular files).
-Each message is stored in a separate file in the format it had been
+Each message is stored in a separate file in the format it was
 received (i.e. transfer format).
 The files are named with ascending numbers in each folder.
 The specific format of the mail storage characterizes MH in the same way
-like the format of the file system characterizes Unix.
+as the format of the file system characterizes Unix.
 .P
 MH tools maintain a \fIcontext\fP, which includes the current mail folder.
 Processes in Unix have a similar context, containing the current working
 directory, for instance. In contrast, the process context is maintained
 by the Unix kernel automatically, whereas MH tools need to maintain the MH
 context themselves.
-The user can have one MH context or multiple ones, he can even share it
+The user can have one MH context or multiple ones; he can even share it
-with other users.
+with others.
 .P
 Messages are named by their numeric filename, but they can have symbolic names,
 too. These are either automatically updated
-position names like being the next or the last message,
+position names such as the next or the last message,
 or user-settable group names for arbitrary sets of messages.
 These names are called sequences.
 Sequences can be bound to the containing folder or to the context.
 .P
 The user's \fIprofile\fP is a file that contains his MH configuration.
 .U2 "Using MH
 .P
 It is strongly recommended to have a look at the MH Book,
-which introduces well into using MH.
+which offers a thorough introduction to using MH.
 .[ [
 peek mh book
 .], Part II]
 Rose and Romine provide a deeper and more technical
 though slightly outdated introduction in only about two dozens pages.
 rose romine real work
 .]
 .P
 Following is an example mail handling session.
 It uses mmh but is mostly compatible with nmh and old MH.
-Details might vary but the look'n'feel is the same.
+Details might vary but the look and feel is the same.
 .VF input/mh-session
 .H1 "nmh: Code and Community
 .P
 In order to understand the condition, goals and dynamics of a project,
-one needs to know the reasons.
+one needs to know the reasons behind them.
 This section explains the background.
 .P
-MH predates the Internet, it comes from times before networking was universal,
+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.
+Then it grew, spread and adapted to the changes email went through.
 Its core-concepts, however, remained the same.
-During the Eighties students at UCI actively worked on MH.
+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 tailored for hardware of that time
 are frequent.
 .P
-Nmh started about a decade after the POSIX and ANSI C standards had been
+Nmh started about a decade after the POSIX and ANSI C standards were
 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.
+base became more diverse, thus broadening the range of different
+coding styles.
 Programming practices from different decades merged in the project.
 As several peers added code, the system became more a conglomeration
 of single tools rather than a homogeneous of-one-cast mail system.
 Still, the existing basic concepts held it together.
 They were mostly untouched throughout the years.
 .P
-Despite the tool chest approach at the surface \(en a collection
+Despite the separation of the tool chest approach at the surface
-of separate small programs \(en on the source code level
+\(en a collection of small, separate programs \(en
-it is much more interweaved.
+on the source code level, it is much more interweaved.
 Several separate components were compiled into one program
 for efficiency reasons.
-This lead to intricate innards.
+This led to intricate innards.
-Unfortunately, the clear separation on the outside appeared as being
+While clearly separated on the outside,
-pretty interweaved inside.
+the programs turned out to be fairly interweaved inside.
-.P
+.\" XXX FIXME rewrite...
-The advent of MIME rose the complexity of email by a magnitude.
+.\" Unfortunately, the clear separation on the outside turned out to be
+.\" fairly interweaved inside.
+.P
+The advent of MIME raised 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.
+It is also visible that MIME support was added on top of the old MH core.
 MH's tool chest style made this easily possible and encourages
-such approaches, but unfortunately, it lead to duplicated functions
+such approaches, but unfortunately, it led 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 explicitly
 to be able to use them.
 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
+However, in the same go, new users have difficulties using nmh for modern
 emailing.
-The small but matured community around nmh hardly needs much change
+The small but mature community around nmh needs few change
-as they have their convenient setups since decades.
+as they have had their convenient setups for decades.
 .H1 "mmh
 .P
 I started to work on my experimental version in October 2011,
-at a time when there were no more than three commits to nmh
+at a time when there had been no more than three commits to nmh
 since the beginning of the year.
 In December, when I announced my work in progress on the
 nmh-workers mailing list,
 .[
 nmh-workers mmh announce December
 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
 .[
 nmh-workers vixie edginess
 .]
 After long years of stagnation, nmh became actively developed again.
-Hence, while I was working on mmh, the community was working on nmh,
+Hence, while I was working on mmh, the community was once more working
-in parallel.
+on nmh, in parallel.
 .P
 The name \fImmh\fP may stand for \fImodern mail handler\fP,
 because the project tries to modernize nmh.
 Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
 emphasizing that the project follows my visions and preferences.
 .P
 MH is the most important of very few command line tool chest email systems.
 Tool chests are powerful because they can be perfectly automated and
 extended. They allow arbitrary kinds of front-ends to be
 implemented on top of them quickly and without internal knowledge.
-Additionally, tool chests are much better to maintain than monolithic
+Additionally, tool chests are easier to maintain than monolithic
 programs.
 As there are few tool chests for emailing and as MH-like ones are the most
-popular among them they should be developed further.
+popular among them, they should be developed further.
 This keeps their
 conceptional elegance and unique scripting qualities available to users.
-Mmh will create a modern and convenient entry point to MH-like systems
+Mmh creates a modern and convenient entry point to MH-like systems
 for new and interested users.
 .P
 The mmh project is motivated by deficits of nmh and
 my wish for general changes, combined
 with the nmh community's reluctancy to change.
 .P
-nmh hadn't adjusted to modern emailing needs well enough.
+At that time, nmh had not adjusted to modern emailing needs well enough.
 The default setup was completely unusable for modern emailing.
 Too much setup work was required.
 Several modern features were already available but the community
-didn't wanted to have them as default.
+did not want to have them as default.
-mmh is a way to change this.
+Mmh is a way to change this.
 .P
 In my eyes, MH's concepts could be exploited even better and
 the style of the tools could be improved. Both would simplify
 and generalize the system, providing cleaner interfaces and more
 software leverage at the same time.
-mmh is a way to demonstrate this.
+Mmh is a way to demonstrate this.
 .P
 In providing several parts of an email system, nmh can hardly
 compete with the large specialized projects that focus
 on only one of the components.
 The situation can be improved by concentrating the development power
 on the most unique part of MH and letting the user pick his preferred
 set of other mail components.
 Today's pre-packaged software components encourage this model.
-mmh is a way to go for this approach.
+Mmh is a way to go for this approach.
 .P
-It's worthwhile to fork nmh for the development of mmh, because
+It is worthwhile to fork nmh for the development of mmh, because
 the two projects focus on different goals and differ in fundamental questions.
-The nmh community's reluctance to change conflicts
+The nmh community's reluctance regarding change conflicts
-with my strong will to change.
+with my strong desire for it.
 In developing a separate experimental version new approaches can
 easily be tried out without the need to discuss changes beforehand.
 In fact, revolutionary changes are hardly possible otherwise.
 .P
-The mmh project provides the basis to implemented and demonstrated
+The mmh project implements and demonstrates the listed ideas
-the listed ideas without the need to change nmh or its community.
+without the need to change nmh or its community.
 Of course, the results of the mmh project shall improve nmh, in the end.
 .U2 "Target Field
 .P
 Any effort needs to be targeted towards a specific goal

Mercurial > docs > master

comparison ch01.roff @ 106:3c4e5f0a7e7b