# HG changeset patch # User markus schnalke # Date 1339526692 -7200 # Node ID 30830e3b9e98072ae98c329de8519517d778dc25 # Parent 7d5b180de5425356b58982c1d4a6b91d20fb8d59 Further rework. diff -r 7d5b180de542 -r 30830e3b9e98 ch03.roff --- a/ch03.roff Tue Jun 12 18:04:55 2012 +0200 +++ b/ch03.roff Tue Jun 12 20:44:52 2012 +0200 @@ -419,20 +419,20 @@ mapped message numbers and sequences to files and invoked .Pn mhl to have the files formated. -For MIME, this approach wasn't sufficient anymore. +With MIME, this approach wasn't sufficient anymore. MIME messages can consist of multiple parts, some of which aren't -directly displayable, and text content might be encoded in +directly displayable, further more text content might be encoded in foreign charsets. .Pn show 's understanding of messages and .Pn mhl 's -limited display facilities couldn't cope with the task any longer. +display capabilities couldn't cope with the task any longer. .P -Instead of extending these tools, additional tools were written from scratch -and then added to the MH tool chest. Doing so is encouraged by the -tool chest approach. The new tools could be added without interfering -with the existing ones. -Modular design is a great advantage for extending a system. +Instead of extending these tools, additional tools were written from +scratch and added to the MH tool chest. +Doing so is encouraged by the tool chest approach. +Modular design is a great advantage for extending a system, +as new tools can be added without interfering with existing ones. First, the new MIME features were added in form of the single program .Pn mhn . The command @@ -441,27 +441,26 @@ With the 1.0 release of nmh in February 1999, Richard Coleman finished the split of .Pn mhn -into a set of specialized programs, which together covered the -multiple aspects of MIME. One of these resulting tools was +into a set of specialized tools, which together covered the +multiple aspects of MIME. +One of them was .Pn mhshow , -which replaced the -.Cl "mhn -show -call. -It was capable to display a MIME message appropriately. +which replaced +.Cl "mhn -show" . +It was capable of displaying MIME messages appropriately. .P -From then on, two message display tools were part of nmh: +From then on, two message display tools were part of nmh, .Pn show and .Pn mhshow . -Because the user should not need to invoke the right tool -whether the message uses MIME or not, +To ease the life of users, .Pn show was extended to automatically hand the job over to .Pn mhshow if displaying the message would be beyond .Pn show 's abilities. -In consequence, the user would invoke +In consequence, the user would simply invoke .Pn show (possibly through .Pn next @@ -472,61 +471,82 @@ or .Pn mhshow , whatever was more appropriate. -(There was also a switch for -.Pn show -to never invoke -.Pn mhshow . -.Pn show -was able to display MIME messages if they contained only a single text -part.) .P Having two similar tools for essentially the same task is redundant. -The development of both programs needed to be in sync, +Usually, +users wouldn't distinguish between +.Pn show +and +.Pn mhshow +in their daily mail reading. +Having two separate display programs was therefore mainly unnecessary +from a user's point of view. +Besides, the development of both programs needed to be in sync, to ensure that the programs behaved in a similar way, because they were used like a single tool. Different behavior would have surprised the user. .P Today, non-MIME messages are rather seen to be a special case of -MIME messages, than MIME messages are seen to be an extension to -original email. +MIME messages, although it's the other way round. As .Pn mhshow -had already be able to display non-MIME messages, it was natural +had already be able to display non-MIME messages, it appeared natural to drop .Pn show in favor of using .Pn mhshow exclusively. -This decision followed the idea of orthogonal design. +.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853 +Removing +.Pn show +is no loss in function, because functionally +.Pn mhshow +covers it completely. +The old behavior of +.Pn show +can still be emulated with the simple command line: +.VS +mhl `mhpath c` +VE +.P For convenience, .Pn mhshow -was then renamed to -.Pn show . -.Ci 4c1efddfd499300c7e74263e57d8aa137e84c853 +was renamed to +.Pn show +after +.Pn show +was gone. +It is clear that such a rename may confuse future developers when +trying to understand the history. +Nevertheless, I consider the convenience on the user's side, +to call +.Pn show +when they want a message to be displayed, to outweigh the inconvenience +on the developer's side when understanding the project history. .P -To prepare for this transition, +To prepare for the transition, .Pn mhshow was reworked to behave more like .Pn show first. -(Section XXX describes this rework from a different perspective.) -Once the tools behaved similar, the replacing became a natural decision. -In mmh, +(cf. Sec. XXX) +Once the tools behaved more alike, the replacing appeared to be +even more natural. +Today, mmh's new .Pn show -is the one single message display program again, but it handles -MIME messages as well as non-MIME messages. -Now, there's only one program to maintain, and users don't need to deal -with the existance of two display programs. +became the one single message display program again, with the difference +that today it handles MIME messages as well as non-MIME messages. +The outcome of the transition is one program less to maintain, +no second display program for users to deal with, +and less system complexity. .P -There's one reason why removing the old +Still, removing the old .Pn show -hurts: It had been such a simple program. -Its lean elegance is missing to -.Pn mhshow , -i.e. the new +hurts in one regard: It had been such a simple program. +Its lean elegance is missing to the new .Pn show . -But there is no chance, because supporting MIME causes essentially -higher complexity. +But there is no chance; +supporting MIME demands for higher essential complexity. .H2 "Removal of Configure Options