In your message dated: Wed, 03 Jul 2002 19:42:48 CDT,
The pithy ruminations from Earl Hood on
<Re: folder-specific defaults? [long]> were:
=> On July 4, 2002 at 00:43, Tobias Nijweide wrote:
=>
I like the concept of folder-specific components very much. In fact, this could
be extended to all sorts of folder-specific settings (different scan filters
for different folders, different sortm flags per-folder, etc.).
=> > 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.
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 file
in a directory is presumed to be a mail message. Throwing meta-files into data
directories will have side effects on things like glimpse indexing and any
custom scripts that do things with every mail message in a directory.
At very least, if the per-folder components files are stored in the data
directories they should be hidden files (which breaks the existing nmh file
naming convention, IMHO).
=> 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. Whatever the storage structure, it will complicate interaction with any
other tools if data files and metadata (components & such) are mixed in the
same storage. I think it's a bad idea to rely on some hard-coded naming
convention or file magic type within nmh to distinguish these files, as other
tools will not be as "smart".
=>
[SNIP!]
=>
=> --ewh
=>
-----
Mark Bergman Biker, Rock Climber, Unix mechanic, IATSE #1 Stagehand
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40merctech.com
I want a newsgroup with a infinite S/N ratio! Now taking CFV on:
rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters
15+ So Far--Want to join? Check out: http://www.panix.com/~bergman