docs/master

diff ch03.roff @ 66:4c9f4d05d90e

Rework and extension of text from yesterday.
author markus schnalke <meillo@marmaro.de>
date Sat, 02 Jun 2012 10:32:26 +0200
parents abbaca05ee8e
children f80ced4e749b
line diff
     1.1 --- a/ch03.roff	Sat Jun 02 10:31:59 2012 +0200
     1.2 +++ b/ch03.roff	Sat Jun 02 10:32:26 2012 +0200
     1.3 @@ -37,8 +37,12 @@
     1.4  .P
     1.5  In contrast to nmh, which also provides mail submission and mail retrieval
     1.6  facilities, mmh is a MUA only.
     1.7 +This general difference in the view on the character of nmh
     1.8 +strongly supported the development of mmh.
     1.9 +Removing the mail transfer facilities had been the first work task
    1.10 +for the mmh project.
    1.11  .P
    1.12 -The MSA is called ``Message Transfer Service'' (MTS) in nmh.
    1.13 +The MSA is called \fIMessage Transfer Service\fP (MTS) in nmh.
    1.14  The facility establishes TCP/IP connections and speaks SMTP to submit
    1.15  messages for relay to the outside world.
    1.16  This part is implemented in the
    1.17 @@ -78,13 +82,12 @@
    1.18  from the system maildrop, or with
    1.19  .Pn rcvstore
    1.20  from the standard input.
    1.21 -.P
    1.22 -In consequence, mmh includes neither networking nor SASL code anymore.
    1.23 -Two large separate functional units are removed.
    1.24 -They account for about XXX lines of code and XXX libraries.
    1.25 +In consequence, mmh has not any longer networking code
    1.26 +and thus does no more need to do transfer encryption and authentication.
    1.27 +Two large functional units are removed.
    1.28  .P
    1.29  With the removal of the MSA and MRA, mmh converted from an all-in-one
    1.30 -mail system to the core: the MUA.
    1.31 +mail system to being only a MUA.
    1.32  Following the Unix philosophy, it focuses on one job and to do that well.
    1.33  Now, of course, mmh depends on third-party software.
    1.34  An external MTA/MSA is required to transfer mail to the outside world;
    1.35 @@ -109,7 +112,7 @@
    1.36  emailing had been small and simple.
    1.37  (Remember,
    1.38  .Pn /bin/mail
    1.39 -had once covered anything there was to email.)
    1.40 +had once covered anything there was to email and still had been small.)
    1.41  As the complexity in emailing increased, MH remainded mostly unchanged.
    1.42  Nontheless, in nmh the POP server, which the original MH had included,
    1.43  was removed. Now is the time to take one step further and remove
    1.44 @@ -118,7 +121,32 @@
    1.45  but more important, it removes the whole field of message transfer
    1.46  with all its implications from the project.
    1.47  .P
    1.48 -Users of MH are usually able to set up an external MSA and MRA.
    1.49 +If a project needs some kind of function, there's always the choice
    1.50 +between implementing the the function in the project directly or
    1.51 +depending on a library that provides the function or depending on
    1.52 +a program that provides the function.
    1.53 +Whereas adding the function directly to the project increases the
    1.54 +code size most, it makes the project most independent.
    1.55 +On the other end, interfacing external programs keeps the interface
    1.56 +smallest, but the depencency highest.
    1.57 +Using a library is in the middle.
    1.58 +Adding the function directly to the project is a bad choice for
    1.59 +any function of higher complexity, unless it's not available in other ways.
    1.60 +Hence, the dependencies only change in kind, not in their existence.
    1.61 +In mmh, library dependencies on
    1.62 +.Pn libsasl2
    1.63 +and
    1.64 +.Pn libcrypto /\c
    1.65 +.Pn libssl
    1.66 +were treated against program dependencies on an MSA and an MRA.
    1.67 +Besides program dependencies providing the stronger separation
    1.68 +and being more flexible, they also allowed
    1.69 +over 6\|000 lines of code to be removed from mmh.
    1.70 +This made mmh's code base about 12\|% smaller.
    1.71 +Reducing the projects code size by such an amount without actually
    1.72 +losing function is a convincing argument.
    1.73 +.P
    1.74 +Users of MH should have not problem to set up an external MSA and MRA.
    1.75  Also, the popular MSAs and MRAs have large communities and a lot
    1.76  of documentation available.
    1.77  .P
    1.78 @@ -212,7 +240,7 @@
    1.79  and
    1.80  .Pn wmh ,
    1.81  saved more than 7\|000 lines of C code \(en
    1.82 -about 15\|% of the project's source code amount.
    1.83 +about 15\|% of the project's original source code amount.
    1.84  Having the same functionality in less code (with equal readability,
    1.85  of course) is an advantage.
    1.86  Less code means less bugs and less maintenance work.