nmh-workers
[Top] [All Lists]

Re: folder-specific defaults? [long]

2002-07-04 14:08:38
On July 4, 2002 at 09:45, bergman(_at_)merctech(_dot_)com wrote:

=> Allow folder specific component files to be located in a centralized
=> location.  For example, if I wanted a custom "scan.monthly" format
=> file for my inbox, I would create a file with a pathname of
=> `mhpath`/scan.monthly.inbox.  It does get ambiguous with sub-folders
=> since '/' cannot be a pathname (maybe tranlate '/' to '.').
=> 
=> The only real reason I bring up this alternative is it protects a user
=> from losing custom format/component files when using the rmf command.

There's another really good reason for this alternative. One of the strong
features of [n]mh is that every mail message is a file, conversely, every fil
e
in a directory is presumed to be a mail message. Throwing meta-files into dat
a
directories will have side effects on things like glimpse indexing and any
custom scripts that do things with every mail message in a directory.

There is already precedence of meta files existing in folder directories
in MH/nmh.  Typically, if doing your own custom programming on message
files, you restrict the set of files to numeric filenames.

=> Placing things in mail folders directly also breaks data abstraction.
=> I.e.  A user of nmh can use nmh without even really caring if a folder
=> is a directory with files, a single file (aka mbox), or some kind of
=> fancy database.

Sometimes the user cares--and assumes--that the folder is really a directory 
of 
files.

The abstraction does not conflict with this.  If an abstraction level
is ever implemented, the default implementation would have to be
capatible with the existing model or you have alot of upset users that
have to muck with some upgrade process and breaking alot of their
custom scripts.

Of course, all implementation should be documented so savvy users
could do custom programming as many do now.

--ewh


<Prev in Thread] Current Thread [Next in Thread>