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-21 13:04:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!wn2feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc53.POSTED!not-for-mail Message-ID: <3D138728.9030605@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal References: <4519e058.0206190708.2ef205e4@posting.google.com> <3D10AF1F.3000805@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc53 1024689870 24.61.239.24 (Fri, 21 Jun 2002 20:04:30 GMT) NNTP-Posting-Date: Fri, 21 Jun 2002 20:04:30 GMT Date: Fri, 21 Jun 2002 20:04:30 GMT Xref: archiver1.google.com comp.lang.ada:26576 Date: 2002-06-21T20:04:30+00:00 List-Id: 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.