On July 4, 2002 at 00:43, Tobias Nijweide wrote:
2 - In earlier discussion, Dan indicated that he would like a flag to turn
this feature on. I'd like to get agreement on details. Where do we look
for component files:
a - If fixed path (Starting with '/', '~', './' or '../'), only one choice.
b - Current, or selected folder
c - Recursive search upwards from current folder, up to:
d - User nmh directory
e - /etc/nmh (or whatever is the value of nmhetcdir)
Just to throw out an alternative to the idea (and a dicussion
that probably goes way out there):
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.
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.
For example, how would this feature work if IMAP capabilities were
incorporated into nmh?
In general, should there eventually be an abstraction of per-folder
component/format files intead of directly relying on a file system.
I could see something like the following scenerio:
shell> compedit +inbox scan.monthly
[Launches users editor to allow editing of a format file *labeled*
scan.monthly for the inbox folder. Once the editor exists, the
"file" is saved according to the folder implementation that
is tied to inbox.]
Such a system would require a folder data abstraction in nmh with
a well-defined API on how a folder implementation interacts with
the nmh core. The implementation that represents the current
filesystem directory-based structure would store component files
in the directory for a give folder while a RDBMS implementation
would store the data in a database.
I guess something like this would not possible happen until nmh 5.0 :-)
--ewh