From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,80b3e504140e89fd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-24 06:43:23 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal Date: 24 Jun 2002 09:39:57 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <4519e058.0206190708.2ef205e4@posting.google.com> <3D10AF1F.3000805@attbi.com> <3D138728.9030605@attbi.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1024926435 604 128.183.220.71 (24 Jun 2002 13:47:15 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 24 Jun 2002 13:47:15 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:26648 Date: 2002-06-24T13:47:15+00:00 List-Id: "Robert I. Eachus" writes: > 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. Ok, I guess I'm being impatient :). > 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. Yes, that is an important use case that I should capture. > 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. Yes. I think that conforms to the current "forbid simultaneous access" requirement, but adds the requirement for an enforcement mechanism. I don't think the GNAT library supports file locking of this type, but it shouldn't be hard to do. It would make the package much safer. > 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.) Windows (and I assume other reasonable OSes) supports "open locked for write", so that no other program can "open for read" while it is locked. Then we need to define what the second program does when it attempts the read; fail with an error message? or wait and timeout with an error message? > The important thing from the specification view here is that the > attempt to change a value or values can fail. Read can also fail, if the file is locked for write. > 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.) I can see that this would work. I don't want to implement it :). We could agree to do choice 1) above first, with this protocol as a later enhancement. > 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. Ok, that makes sense. One alternative is to have the writer broadcast some sort of message, which is way more complex. That's what the Windows registry does; I assume Gnome gconf does something similar. Without instant notification of changes it will be pretty easy to set up situations that will confuse the user. But maybe we can live with it. > 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. Hmm. The current app can only change the "last" config file. But some other app may have one of the other config files as its "writable" file, so any of the 27 may change. I don't think we want to ignore those changes. > 3) Chaos. Hmm. Are you saying that simply forbidding access by multiple processes, without an enforcement mechanism, is a recipe chaos? I guess that could be true. Users will ignore warnings in the application documentation, since they won't read it :). -- -- Stephe