docs/master

changeset 88:30830e3b9e98

Further rework.
author markus schnalke <meillo@marmaro.de>
date Tue, 12 Jun 2012 20:44:52 +0200
parents 7d5b180de542
children 83bfb4dbf59f
files ch03.roff
diffstat 1 files changed, 68 insertions(+), 48 deletions(-) [+]
line diff
     1.1 --- a/ch03.roff	Tue Jun 12 18:04:55 2012 +0200
     1.2 +++ b/ch03.roff	Tue Jun 12 20:44:52 2012 +0200
     1.3 @@ -419,20 +419,20 @@
     1.4  mapped message numbers and sequences to files and invoked
     1.5  .Pn mhl
     1.6  to have the files formated.
     1.7 -For MIME, this approach wasn't sufficient anymore.
     1.8 +With MIME, this approach wasn't sufficient anymore.
     1.9  MIME messages can consist of multiple parts, some of which aren't
    1.10 -directly displayable, and text content might be encoded in
    1.11 +directly displayable, further more text content might be encoded in
    1.12  foreign charsets.
    1.13  .Pn show 's
    1.14  understanding of messages and
    1.15  .Pn mhl 's
    1.16 -limited display facilities couldn't cope with the task any longer.
    1.17 +display capabilities couldn't cope with the task any longer.
    1.18  .P
    1.19 -Instead of extending these tools, additional tools were written from scratch
    1.20 -and then added to the MH tool chest. Doing so is encouraged by the
    1.21 -tool chest approach. The new tools could be added without interfering
    1.22 -with the existing ones.
    1.23 -Modular design is a great advantage for extending a system.
    1.24 +Instead of extending these tools, additional tools were written from
    1.25 +scratch and added to the MH tool chest.
    1.26 +Doing so is encouraged by the tool chest approach.
    1.27 +Modular design is a great advantage for extending a system,
    1.28 +as new tools can be added without interfering with existing ones.
    1.29  First, the new MIME features were added in form of the single program
    1.30  .Pn mhn .
    1.31  The command
    1.32 @@ -441,27 +441,26 @@
    1.33  With the 1.0 release of nmh in February 1999, Richard Coleman finished
    1.34  the split of
    1.35  .Pn mhn
    1.36 -into a set of specialized programs, which together covered the
    1.37 -multiple aspects of MIME. One of these resulting tools was
    1.38 +into a set of specialized tools, which together covered the
    1.39 +multiple aspects of MIME.
    1.40 +One of them was
    1.41  .Pn mhshow ,
    1.42 -which replaced the
    1.43 -.Cl "mhn -show
    1.44 -call.
    1.45 -It was capable to display a MIME message appropriately.
    1.46 +which replaced
    1.47 +.Cl "mhn -show" .
    1.48 +It was capable of displaying MIME messages appropriately.
    1.49  .P
    1.50 -From then on, two message display tools were part of nmh:
    1.51 +From then on, two message display tools were part of nmh,
    1.52  .Pn show
    1.53  and
    1.54  .Pn mhshow .
    1.55 -Because the user should not need to invoke the right tool
    1.56 -whether the message uses MIME or not,
    1.57 +To ease the life of users,
    1.58  .Pn show
    1.59  was extended to automatically hand the job over to
    1.60  .Pn mhshow
    1.61  if displaying the message would be beyond
    1.62  .Pn show 's
    1.63  abilities.
    1.64 -In consequence, the user would invoke
    1.65 +In consequence, the user would simply invoke
    1.66  .Pn show
    1.67  (possibly through
    1.68  .Pn next
    1.69 @@ -472,61 +471,82 @@
    1.70  or
    1.71  .Pn mhshow ,
    1.72  whatever was more appropriate.
    1.73 -(There was also a switch for
    1.74 -.Pn show
    1.75 -to never invoke
    1.76 -.Pn mhshow .
    1.77 -.Pn show
    1.78 -was able to display MIME messages if they contained only a single text
    1.79 -part.)
    1.80  .P
    1.81  Having two similar tools for essentially the same task is redundant.
    1.82 -The development of both programs needed to be in sync,
    1.83 +Usually,
    1.84 +users wouldn't distinguish between
    1.85 +.Pn show
    1.86 +and
    1.87 +.Pn mhshow
    1.88 +in their daily mail reading.
    1.89 +Having two separate display programs was therefore mainly unnecessary
    1.90 +from a user's point of view.
    1.91 +Besides, the development of both programs needed to be in sync,
    1.92  to ensure that the programs behaved in a similar way,
    1.93  because they were used like a single tool.
    1.94  Different behavior would have surprised the user.
    1.95  .P
    1.96  Today, non-MIME messages are rather seen to be a special case of
    1.97 -MIME messages, than MIME messages are seen to be an extension to
    1.98 -original email.
    1.99 +MIME messages, although it's the other way round.
   1.100  As
   1.101  .Pn mhshow
   1.102 -had already be able to display non-MIME messages, it was natural
   1.103 +had already be able to display non-MIME messages, it appeared natural
   1.104  to drop
   1.105  .Pn show
   1.106  in favor of using
   1.107  .Pn mhshow
   1.108  exclusively.
   1.109 -This decision followed the idea of orthogonal design.
   1.110 +.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
   1.111 +Removing
   1.112 +.Pn show
   1.113 +is no loss in function, because functionally
   1.114 +.Pn mhshow
   1.115 +covers it completely.
   1.116 +The old behavior of
   1.117 +.Pn show
   1.118 +can still be emulated with the simple command line:
   1.119 +.VS
   1.120 +mhl `mhpath c`
   1.121 +VE
   1.122 +.P
   1.123  For convenience,
   1.124  .Pn mhshow
   1.125 -was then renamed to
   1.126 -.Pn show .
   1.127 -.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853
   1.128 +was renamed to
   1.129 +.Pn show
   1.130 +after
   1.131 +.Pn show
   1.132 +was gone.
   1.133 +It is clear that such a rename may confuse future developers when
   1.134 +trying to understand the history.
   1.135 +Nevertheless, I consider the convenience on the user's side,
   1.136 +to call
   1.137 +.Pn show
   1.138 +when they want a message to be displayed, to outweigh the inconvenience
   1.139 +on the developer's side when understanding the project history.
   1.140  .P
   1.141 -To prepare for this transition,
   1.142 +To prepare for the transition,
   1.143  .Pn mhshow
   1.144  was reworked to behave more like
   1.145  .Pn show
   1.146  first.
   1.147 -(Section XXX describes this rework from a different perspective.)
   1.148 -Once the tools behaved similar, the replacing became a natural decision.
   1.149 -In mmh,
   1.150 +(cf. Sec. XXX)
   1.151 +Once the tools behaved more alike, the replacing appeared to be
   1.152 +even more natural.
   1.153 +Today, mmh's new
   1.154  .Pn show
   1.155 -is the one single message display program again, but it handles
   1.156 -MIME messages as well as non-MIME messages.
   1.157 -Now, there's only one program to maintain, and users don't need to deal
   1.158 -with the existance of two display programs.
   1.159 +became the one single message display program again, with the difference
   1.160 +that today it handles MIME messages as well as non-MIME messages.
   1.161 +The outcome of the transition is one program less to maintain,
   1.162 +no second display program for users to deal with,
   1.163 +and less system complexity.
   1.164  .P
   1.165 -There's one reason why removing the old
   1.166 +Still, removing the old
   1.167  .Pn show
   1.168 -hurts: It had been such a simple program.
   1.169 -Its lean elegance is missing to
   1.170 -.Pn mhshow ,
   1.171 -i.e. the new
   1.172 +hurts in one regard: It had been such a simple program.
   1.173 +Its lean elegance is missing to the new
   1.174  .Pn show .
   1.175 -But there is no chance, because supporting MIME causes essentially
   1.176 -higher complexity.
   1.177 +But there is no chance;
   1.178 +supporting MIME demands for higher essential complexity.
   1.179  
   1.180  
   1.181  .H2 "Removal of Configure Options