Re: Config_Files proposal

["Robert I. Eachus" <rieachus@attbi.com>]

Stephen Leake wrote:


> Well, I posted those a couple weeks ago, so I thought we did that. It
> did not stimulate much discussion of the specific requirements or
> package spec; all of the discussion was on the file format.


Ah, what was missing was not your draft requirements and interface, what 
was missing was the debate about the requirements.  That is finally 
starting to show up, so let me weigh in on the concurrent access issue. ;-)

There are really two separate sets of concerns here.  First, an 
application which expects users to edit the config file implicitly 
during program installation.  Later edits will be with a text editor, or 
a separate program that changes the config data.  For such uses, the 
semantics are pretty simple.  The program checks a potentially multiple 
set of config at initialization time, changes nothing, and edits while 
the program is running can either be left implementation dependent, or 
defined to be not seen.

A program which is going to change its config attributes during 
operation is a horse of a different color.  As I see it, the three 
choices are:

1) Opening the config for writing means that other instances of the 
program, or other programs that use the same file must either die with 
some reasonable behavior, or connect somehow to the first running 
instance.  Defining how to do the latter is well beyond the scope here.

2)  A program which can change the config file is required to follow a 
standard protocol. An example would be:

     a) If the config data is changed, the program uses a locking 
protocol of some sort to insure that there are no race conditions.  (For 
example, under Windows opening the file before the change works.)  The 
important thing from the specification view here is that the attempt to 
change a value or values can fail.  Whether the user view is an explicit 
  transaction protocol, or a multiple change commit protocol that can 
raise an exception is a detailed design decision.  (Although I favor the 
latter, with an exception occurance string that should be meaningful to 
the actual end user.)

     b) If the config file is changed by some other program or some 
other instance, the program will check for changes at defined points. 
Of course, these points will be defined by the program, but a good 
starting point would be to always check for changes before creating a 
new window or a new file, and of course before changing any config 
parameters.

     c)  If the program "rolls up" a set of config data from several 
locations, all values inherited from files other than the last will not 
be checked for changes while the program is running.  If you have 27 
files in the config path, only the last will be modified, or checked for 
changes while the program is running.

3) Chaos.