docs/master: discussion.roff comparison

comparison discussion.roff @ 126:3aafbd32d77b

Reworked the User Data Location (Separation) section.

author	markus schnalke <meillo@marmaro.de>
date	Sat, 30 Jun 2012 16:50:35 +0200
parents	0e102cec0c73
children	4a9a97d9d6b5

comparison

equal deleted inserted replaced

-:0e102cec0c73
+:3aafbd32d77b
 can be developed to allow automated testing at compile time.
-.H2 "Separation
+.H2 "User Data Locations
+.P
-.U3 "MH Directory Split
+In nmh, a personal setup consists of the MH profile and the MH directory.
-.P
+The profile is a file named
-In MH and nmh, a personal setup had consisted of two parts:
-The MH profile, named
 .Fn \&.mh_profile
-and being located directly in the user's home directory.
+in the user's home directory.
-And the MH directory, where all his mail messages and also his personal
+It contains the static configuration.
-forms, scan formats, other configuration files are stored.
+It also contains the location of the MH directory in the profile entry
-The location
+.Pe Path .
-of this directory could be user-chosen.
+The MH directory contains the mail storage and is the first
-The default was to name it
+place to search for personal forms, scan formats, and similar
+configuration files.
+The location of the MH directory can be chosen freely by the user.
+The default and usual name is a directory named
 .Fn Mail
-and have it directly in the home directory.
+in the home directory.
 .P
-I've never liked the data storage and the configuration to be intermixed.
+The way MH data is splitted between profile and MH directory is a legacy.
-They are different kinds of data.
+It is only sensible in a situation where the profile is the only
-One part, are the messages,
+configuration file.
-which are the data to operate on.
+Why else should the mail storage and the configuration files be intermixed?
-The other part, are the personal
+They are different kinds of data:
-configuration files, which are able to change the behavior of the operations.
+The data to be operated on and the configuration to change how
-The actual operations are defined in the profile, however.
+tools operate.
-.P
+Splitting the configuration between the profile and the MH directory
-When storing data, one should try to group data by its type.
+is bad.
-There's sense in the Unix file system hierarchy, where configuration
+Merging the mail storage and the configuration in one directory is bad
-file are stored separate (\c
+as well.
-.Fn /etc )
+As the mail storage and the configuration were not separated sensibly
-to the programs (\c
+in the first place, I did it now.
-.Fn /bin
+.P
-and
+Personal mmh data is grouped by type, resulting in two distinct parts:
-.Fn /usr/bin )
+The mail storage and the configuration.
-to their sources (\c
+In mmh, the mail storage directory still contains all the messages,
-.Fn /usr/src ).
+but, in exception of public sequences files, nothing else.
-Such separation eases the backup management, for instance.
+In difference to nmh, the auxiliary configuration files are no longer
-.P
+located there.
-In mmh, I've reorganized the file locations.
+Therefore, the directory is no longer called the user's \fIMH directory\fP
-Still there are two places:
+but his \fImail storage\fP.
-There's the mail storage directory, which, like in MH, contains all the
+Its location is still user-chosen, with the default name
-messages, but, unlike in MH, nothing else.
-Its location still is user-chosen, with the default name
 .Fn Mail ,
 in the user's home directory.
-This is much similar to the case in nmh.
+In mmh, the configuration is grouped together in
-The configuration files, however, are grouped together in the new directory
+the hidden directory
 .Fn \&.mmh
 in the user's home directory.
-The user's profile now is a file, named
+This \fImmh directory\fP contains the context file, personal forms,
-.Fn profile ,
+scan formats, and the like, but also the user's profile, now named
-in this mmh directory.
+.Fn profile .
-Consistently, the context file and all the personal forms, scan formats,
+The location of the profile is no longer fixed to
-and the like, are also there.
+.Fn $HOME/.mh_profile
-.P
+but to
-The naming changed with the relocation.
+.Fn $HOME/.mmh/profile .
-The directory where everything, except the profile, had been stored (\c
+Having both, the file
-.Fn $HOME/Mail ),
+.Fn $HOME/.mh_profile
-used to be called \fIMH directory\fP.
+and the configuration directory
-Now, this directory is called the
+.Fn $HOME/.mmh
-user's \fImail storage\fP.
+appeared to be inconsistent.
-The name \fImmh directory\fP is now given to
+The approach chosen for mmh is consistent, simple, and familiar to
-the new directory
+Unix users.
-(\c
+.P
-.Fn $HOME/.mmh ),
+MH allows users to have multiiple MH setups.
-containing all the personal configuration files.
+Therefore, it is necessary to select a different profile.
-.P
+The profile is the single entry point to access the rest of a
-The separation of the files by type of content is logical and convenient.
+personal MH setup.
-There are no functional differences as any possible setup known to me
+In nmh, the environment variable
-can be implemented with both approaches, although likely a bit easier
-with the new approach.
-The main goal of the change had been to provide
-sensible storage locations for any type of personal mmh file.
-.P
-In order for one user to have multiple MH setups, he can use the
-environment variable
 .Ev MH
-the point to a different profile file.
+could be used to specifiy a different profile.
-The MH directory (mail storage plus personal configuration files) is
+To operate in the same MH setup with a separate context,
-defined by the
+the
-.Pe Path
-profile entry.
-The context file could be defined by the
-.Pe context
-profile entry or by the
 .Ev MHCONTEXT
-environment variable.
+environment variable could be used.
-The latter is useful to have a distinct context (e.g. current folders)
+This allows having own current folders and current messages in
-in each terminal window, for instance.
+each terminal, for instance.
-In mmh, there are three environment variables now.
+In mmh, three environment variables are used.
 .Ev MMH
-may be used to change the location of the mmh directory.
+overrides the default location of the mmh directory (\c
+.Fn .mmh ).
 .Ev MMHP
 and
 .Ev MMHC
-change the profile and context files, respectively.
+override the paths to the profile and context files, respectively.
-Besides providing a more consistent feel (which simply is the result
+This approach allows the set of personal configuration files to be chosen
-of being designed anew), the set of personal configuration files can
+independently from the profile, context, and mail storage.
-be chosen independently from the profile (including mail storage location)
+.P
-and context, now.
+The separation of the files by type is sensible and convenient.
-Being it relevant for practical use or not, it
+The new approach has no functional disadvantages,
-de-facto is an improvement.
+as every setup I can imagine can be implemented with both approaches,
-However, the main achievement is the
+possibly even easier with the new approach.
-split between mail storage and personal configuration files.
+The main achievement of the change is the clear and sensible split
+between mail storage and configuration.

Mercurial > docs > master

comparison discussion.roff @ 126:3aafbd32d77b