gnupg for a multiuser system

[rhkelly]

Mark H. Wood wrote:

> On Thu, 6 Nov 2003, rhkelly wrote:
> 
>>Which shows, once again, why it is *wrong* for application
>>developers to follow Microsoft's directive to store application
>>environmental data in the system registry....
...
> There's nothing wrong with it.  It's just another namespace.  
 > How would you do this differently?  (Technically, yes, per-user
 > data don't belong in the SYSTEM hive; they belong in each 
user's hive.
 > Is that what you're saying?)

No, far from it. This is how it should be done... But first:

Principle #1: An application should be 'fused' to a given
computer as little as possible.

Principle #2: The user should be given as much flexibility
in selecting the location of his or her data (and as much ease
of changing the location of this data between the invocations
of the program) as possible.

#Principle #3: No application should ever write data to files
or locations that the user is not aware of.

(If you disagree with the above three principles - I call them
'principles of a well-behaved, user friendly application (as 
opposed to the 'operating system vendor ('Winoze Logo")
friendly' application :) - please feel free to ignore the rest
of this post; its purpose is *not* to convince anyone that they
are right, it is only to offer a modest suggestion (one among
many) to those that agree with them).

Ancillary files that make the operation of the program
possible, and do not contain *any* reference to, or are
changed by, a particular user ('resources', documentation...)
should be co-located with the 'executable'. If they are
numerous (for instance, illustration image files of a large
html manual, their 'collections' might be placed in a
common subdirectory co-located with the executable.
The program can thus locate and access such files without
any intervention from the user or any prior knowledge of its
whereabouts by the operating system; even if this location
has been changed between the invocations. (remember long and
repeated discussions about gpg on a removable memory 'key'
on this very list?)

The location of *all* user-specific files (this includes
the user identification and customization as well as the
operational data) may be assumed by the program to reside
in the 'standard' operating-system-convention specific places
(...\Application Data\someappname\..., '.someappname/' in
$HOME etc.) if - and only if - no indication is provided by
the user where the data is at the program invocation time.
There are many forms in which this information can be provided;
my favorite is simply the directory name given on the command
line that invokes the program. This can be easily 'stiched in'
the interface-encapsulating objects of a any GUI system.

(Foa a classic example of this approach I offer Eudora 3.x;
an old but still well-used mail client on low-end Widoze
boxes worldwide).

cheers, Roger