--- a/discussion.roff	Wed Jul 04 16:23:01 2012 +0200
+++ b/discussion.roff	Wed Jul 04 16:28:39 2012 +0200
@@ -104,8 +104,7 @@
 For example, a wrapper script for qmail would be:
 .VS
 #!/bin/sh
-# ignore command line arguments
-exec qmail-inject
+exec qmail-inject  # ignore command line arguments
 VE
 The requirement to parse the recipient addresses out of the message header 
 is likely to be removed in the future.
@@ -3275,36 +3274,193 @@
 
 .H2 "Profile Reading
 .P
-FIXME XXX
-
-commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8
-Author: markus schnalke <meillo@marmaro.de>
-Date:   Wed Jun 27 14:23:35 2012 +0200
-
-    spost: Read profile and context now. Removed -library switch.
-    spost is a full part of the mmh toolchest, hence, it shall read the
-    profile/context. This will remove the need to pass profile information
-    from send to spost via command line switches.
-    In January 2012, there had been a discussion on the nmh-workers ML
-    whether post should read the profile/context. There wasn't a clear
-    answer. It behavior was mainly motivated by the historic situation,
-    it seems. My opinion on the topic goes into the direction that every
-    tool that is part of the mmh toolchest should read the profile. That
-    is a clear and simple concept. Using MH tools without wanting to
-    interact with MH (like mhmail had been) is no more a practical problem.
-
-commit 32d4f9daaa70519be3072479232ff7be0500d009
-Author: markus schnalke <meillo@marmaro.de>
-Date:   Wed Jun 27 13:15:47 2012 +0200
-
-    mhmail: Read the context!
-    mhmail will change from a mailx-replacment to an alternative to
-    `comp -ed prompter', thus being a send front-end. Hence, mhmail
-    should not stay outside the profile/context respecting mmh toolchest.
-
-
-slocal
-
+The MH profile contains the configuration for the user-specific MH setup.
+MH tools read the profile right after starting up,
+as it contains the location of the user's mail storage
+and similar settings that influence the whole setup.
+Further more, the profile contains the default switches for the tools,
+hence, it must be read before the command line switches are processed.
+.P
+For historic reasons, some MH tools did not read the profile and context.
+Among them were
+.Pn post /\c
+.Pn spost ,
+.Pn mhmail ,
+and
+.Pn slocal .
+The reason why these tools ignored the profile were not clearly stated.
+During the discussion on the nmh-workers mailing list,
+.[
+nmh-workers levine post profile
+.]
+David Levine posted an explanation, quoting John Romine:
+.QS
+I asked John Romine and here's what he had to say, which
+agrees and provides an example that convinces me:
+.QS
+My take on this is that post should not be called by
+users directly, and it doesn't read the .mh_profile
+(only front-end UI programs read the profile).
+.QP
+For example, there can be contexts where post is called
+by a helper program (like 'mhmail') which may be run by
+a non-MH user.  We don't want this to prompt the user
+to create an MH profile, etc.
+.QP
+My suggestion would be to have send pass a (hidden)
+`\-fileproc proc' option to post if needed.  You could also
+use an environment variable (I think send/whatnow do
+this).
+.QE
+I think that's the way to go.  My personal preference is to use a command line option, not an environment variable.
+.QE
+.P
+To solve the problem of
+.Pn post
+not honoring the
+.Pe fileproc
+profile entry,
+the community roughly agreed that a switch
+.Sw -fileproc
+should be added to
+.Pn post
+to be able to pass a different fileproc.
+I strongly disagree with this approach because it does not solve
+the problem; it only removes a single symptom.
+The problem is that
+.Pn post
+does not behave as expected.
+But all programs should behave as expected.
+Clear and simple concepts are a precondition for this.
+Hence, the real solution is having all MH tools read the profile.
+.P
+Yet, the problem has a further aspect.
+It mainly originates in
+.Pn mhmail .
+.Pn mhmail
+was intended to be a replacement for
+.Pn mailx
+on systems with MH installations.
+.Pn mhmail
+should have been able to use just like
+.Pn mailx ,
+but sending the message via MH's
+.Pn post
+instead of
+.Pn sendmail .
+Using
+.Pn mhmail
+should not be influenced by the question whether the user had
+MH set up for himself or not.
+.Pn mhmail
+did not read the profile as this requests the user to set up MH
+if not done yet.
+As
+.Pn mhmail
+used
+.Pn post ,
+.Pn post
+could not read the profile neither.
+This is the reason why
+.Pn post
+does not read the profile.
+This is the reason for the actual problem.
+It was not much of a problem because
+.Pn post
+was not intended to be used by users directly.
+.Pn send
+is the interactive front-end to
+.Pn post .
+.Pn send
+read the profile and passed all relevant values on the command line to
+.Pn post
+\(en an awkward solution.
+.P
+The important insight is that
+.Pn mhmail
+is no true MH tool.
+The concepts broke because this outlandish tool was treated as any other
+MH tool.
+Instead it should have been treated accordingly to its foreign style.
+The solution is not to prevent the tools reading the profile but
+to instruct them reading a different profile.
+.Pn mhmail
+could have set up a well-defined profile and caused all MH tools
+in the session use it by exporting an environment variable.
+With this approach, no special cases would have been introduced,
+no surprises would have been caused.
+By writing a clean-profile-wrapper, the concept could have been
+generalized orthogonally to the whole MH toolchest.
+Then Rose's motivation behind the decision that
+.Pn post
+ignores the profile, as quoted by Jeffrey Honig,
+.[
+nmh-workers post profile
+.]
+would have become possible:
+.QS
+when you run mh commands in a script, you want all the defaults to be
+what the man page says.
+when you run a command by hand, then you want your own defaults...
+.QE
+.LP
+Yet, I consider this explanation short-sighted.
+We should rather regard theses two cases as just two different MH setups,
+based on two different profiles.
+Mapping such problems on the concepts of switching between different
+profiles, solves them once for all.
+.P
+In mmh, the wish to have
+.Pn mhmail
+as as replacement for
+.Pn mailx
+is considered obsolete.
+Mmh's
+.Pn mhmail
+does no longer cover this use-case.
+Currently,
+.Pn mhmail
+is in a transition state.
+.Ci 32d4f9daaa70519be3072479232ff7be0500d009
+It may become a front-end to
+.Pn comp ,
+which provides an interface more convenient in some cases.
+In this case,
+.Pn mhmail
+will become an ordinary MH tool, reading the profile.
+If, however, this idea will not convince, then
+.Pn mhmail
+will be removed.
+.P
+Every program in the mmh toolchest reads the profile.
+The only exception is
+.Pn slocal ,
+which is not considered part of the mmh toolchest.
+This MDA is only distributed with mmh, currently.
+Mmh has no
+.Pn post
+program, but
+.Pn spost ,
+which now reads the profile.
+.Ci 3e017a7abbdf69bf0dff7a4073275961eda1ded8
+With this change,
+.Pn send
+and
+.Pn spost
+can be considered to be merged.
+Direct invocations of
+.Pn spost
+are only done by the to-be-changed
+.Pn mhmail
+implementation and by
+.Pn rcvdist ,
+which will require rework.
+.P
+The
+.Fu context_foil()
+function to pretend to have read an empty profile was removed.
+.Ci 68af8da96bea87a5541988870130b6209ce396f6
+All mmh tools read the profile.