docs/master

changeset 116:4fbd14dc5e91

Wrote about modern defaults.
author markus schnalke <meillo@marmaro.de>
date Mon, 25 Jun 2012 20:48:36 +0200
parents 7dc4867fef91
children 97369a93ef39
files discussion.roff
diffstat 1 files changed, 77 insertions(+), 12 deletions(-) [+]
line diff
     1.1 --- a/discussion.roff	Mon Jun 25 14:19:41 2012 +0200
     1.2 +++ b/discussion.roff	Mon Jun 25 20:48:36 2012 +0200
     1.3 @@ -2382,29 +2382,94 @@
     1.4  
     1.5  .H2 "Modern Defaults
     1.6  .P
     1.7 -Nmh has a bunch of convenience-improving features available,
     1.8 -but they are inactive by default.
     1.9 -The user needs to activate them.
    1.10 -Today one can expect every new user to want to have them available.
    1.11 +Nmh has a bunch of convenience-improving features inactive by default,
    1.12 +although one can expect every new user wanting to have them active.
    1.13  The reason they are inactive by default is the wish to stay compatible
    1.14  with old versions.
    1.15 -Surprisingly, the community seems not to care that the highly useful
    1.16 -draft folder still is not available by default although it had been
    1.17 -introduced over twenty-five years ago.
    1.18 +But what is the definition for old versions.
    1.19 +Still, the highly useful draft folder facility is not active by default
    1.20 +although it had been introduced over twenty-five years ago
    1.21  .[
    1.22  rose romine real work
    1.23  .]
    1.24 -This is one of several examples that require new users to first
    1.25 -build up an extensive profile in order to convert the default
    1.26 -nmh installation into a convenient state.
    1.27 +\(en the community seems not to care.
    1.28 +This is one of several examples that require new users to build up
    1.29 +their profile before they can access the modern features of nmh.
    1.30 +Without an extensively built-up profile, the setup is hardly usable
    1.31 +for modern emailing.
    1.32 +The point is not the customization of the setup,
    1.33 +but the activating of generally useful facilities.
    1.34  .P
    1.35 -To give an example, it took one year of using nmh
    1.36 +Yet, the real problem lies less in enabling the features, as this is
    1.37 +straight forward as soon as one knows what he wants.
    1.38 +The real problem is that new users need deep insights into the project
    1.39 +before they find out what they are missing and that nmh actually
    1.40 +provides it already, it just was not activated.
    1.41 +To give an example, I needed one year of using nmh
    1.42  before I became aware of the existence of the attachment system.
    1.43  One could argue that this fact disqualifies my reading of the
    1.44  documentation.
    1.45  If I would have installed nmh from source back then, I could agree.
    1.46 -Yet I had used a prepackaged version and had expected that it would
    1.47 +Yet, I had used a prepackaged version and had expected that it would
    1.48  just work.
    1.49 +Nevertheless, I had been conviced by the concepts of MH already
    1.50 +and I am a software developer,
    1.51 +still I required a lot of time to discover the cool features.
    1.52 +How can we expect users to be even more advanced than me,
    1.53 +just to allow them use MH in a convenient and modern way?
    1.54 +Unless they are strongly convinced of the concepts, they will fail.
    1.55 +I have seen friends of me giving up disappointed
    1.56 +before they truly used the system,
    1.57 +although they had been motivated in the beginning.
    1.58 +They suffer hard enough to get used to the toolchest approach,
    1.59 +we should spare them further inconveniences.
    1.60 +.P
    1.61 +Maintaining compatibility for its own sake is for no good.
    1.62 +If any MH implementation would be the back-end of widespread
    1.63 +email clients with large user bases, compatibility would be more
    1.64 +important.
    1.65 +Yet, it appears as if this is not the case.
    1.66 +Hence, compatibility is hardly important for technical reasons.
    1.67 +Its importance originates rather from personal reasons.
    1.68 +Nmh's user base is small and old.
    1.69 +Changing the interfaces would cause inconvenience to long-term users of MH.
    1.70 +It would force them to change their many years old MH configurations.
    1.71 +I do understand this aspect, but it keeps new users from using MH.
    1.72 +By sticking to the old users, new users are kept away.
    1.73 +Yet, the future lies in new users.
    1.74 +Hence, mmh invites new users by providing a convenient and modern setup,
    1.75 +readily usable out-of-the-box.
    1.76 +.P
    1.77 +In mmh, all modern features are active by default.
    1.78 +In consequence, a setup with a profile that defines only the path to the
    1.79 +mail storage, is already convenient to use.
    1.80 +Again, Paul Vixie's ``edginess'' appeal supports the direction I took:
    1.81 +``the `main branch' should just be modern''.
    1.82 +.[
    1.83 +paul vixie edginess nmh-workers
    1.84 +.]
    1.85 +.P
    1.86 +Modern features that are active in mmh by default include: 
    1.87 +.BU
    1.88 +The attachment system (\c
    1.89 +.Hd Attach ).
    1.90 +.Ci 8ff284ff9167eff8f5349481529332d59ed913b1
    1.91 +.BU
    1.92 +The draft folder facility (\c
    1.93 +.Fn +drafts ).
    1.94 +.Ci 337338b404931f06f0db2119c9e145e8ca5a9860
    1.95 +.BU
    1.96 +The unseen sequence (`u')
    1.97 +.Ci c2360569e1d8d3678e294eb7c1354cb8bf7501c1
    1.98 +and the sequence negation prefix (`!').
    1.99 +.Ci db74c2bd004b2dc9bf8086a6d8bf773ac051f3cc
   1.100 +.BU
   1.101 +Quoting the original message in the reply.
   1.102 +.Ci 67411b1f95d6ec987b4c732459e1ba8a8ac192c6
   1.103 +.BU
   1.104 +Forwarding messages using MIME.
   1.105 +.Ci 6e271608b7b9c23771523f88d23a4d3593010cf1
   1.106 +
   1.107  
   1.108  
   1.109