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-20 07:03:07 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: 20 Jun 2002 10:03:11 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3D0FAC67.A4861809@san.rr.com> <3D10B6B1.AFE9D4E8@san.rr.com> <3D10E046.E604231D@san.rr.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 1024582251 12195 128.183.220.71 (20 Jun 2002 14:10:51 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 20 Jun 2002 14:10:51 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:26482 Date: 2002-06-20T14:10:51+00:00 List-Id: Darren New writes: > Stephen Leake wrote: > > Ok. Do you think that prevents us from agreeing on which file format > > to go forward with? > > I'm not sure why you're implementing two bodies while the spec is still in > flux. :-) Either file format you want to support is OK by me. Fair enough. > > > What about values you don't change? > > > > As I said below, only values changed since being read from the config > > file will be written; unchanged values are not written. > > Then you're screwed. If I load 20 values out of a config file, change one, > and save it, then I'll lose 19 config values? Yes, this is bad. > > > What about values that you change back to match what's in > > > /usr/local/app/config? > > > > Well, I guess we could provide an "undo" command. I guess "undo" can > > simply delete the value from the writeable tree, which will expose the > > value in the read-only tree (assuming there is one). > > I don't think that's quite what I meant. I meant that default values > probably shouldn't be stored, even if you got them by assigning the default > to the key. Yes. The default is provided again with every call to "read", so it does not need to be stored. > I think until you (we) work out the semantics of what's going on, > implementing multiple bodies is relatively unhelpful to progressing > the spec. Well, I usually find problems with a spec when I get around to implementing the body. I did these two implementations to see if there were any problems with the spec that were related to the file format. I don't think there are. > Of course, if you're enjoying it and all, that's something else. :-) I was trying to eliminate one of the variables in the problem. If we agree on what the file format is, that's one less thing to think about. I think we are ready to do that, and it will allow people to focus solely on the spec, rather than on the XML vs ini etc. > > Seriously, you've set up a race condition, which is an indication > > of bad design. If you want multiple instances of your app running, > > each with its own persistent window positions, you need multiple > > config files. That is precisely one of my use cases, and why I > > argued for specifying the config file on the app command line. > > That's not what I'm saying. > > I'm saying I open my text editor for file XYZ.ads, and another for XYZ.adb, > and then I move XYZ.adb off to the side. Then, in XYZ.ads, I configure all > kinds of things to do the proper indenting for Ada, and then I close > XYZ.ads. Since I want XYZ.adb to see these changes, I close that, and reopen > it. Unfortunately, XYZ.adb didn't reload any changes I made in the indenting > configuration section, so all that work's gone. Let's see. You have two instances of "text_edit", sharing one config file. That is explicitly forbidden by requirement 1. So if you want this behavior, you have to use the registry or gconf, not Config_Files. > Bad news. > > Relatively easy to fix - when a config file is saved, it is first read off > the disk, then any values in the in-memory configuration that differ from > the just-loaded configuration and which have been changed since they were > loaded (or since the last save?) are copied to the just-loaded > configuration, then the just-loaded configuration is written back out. This is a race condition. Suppose two processes happen to start a "flush" operation "at the same time"? Whichever goes last wins. That's why we have requirement 1. Config_Files don't do this. If you feel that makes Config_Files totally useless, I guess we can talk about removing requirement 1 and see if we can come up with locking semantics to fix it. But I'd rather not, especially since the registry and gconf have already done that. In general, I suggest that there are other ways to fix an apparent need for concurrent access to config files. For the specific case of a text editor, you can use a text editor that supports multiple documents; that provides automatic sharing of config file settings between XYZ.adb and XYZ.ads. > > > I think if you're not careful, there's going to be very > > > unintuitive behavior. > > > > Which is why we ruled out multiple processes from the beginning. > > OK. I'd misinterpreted, thinking you meant only one process could read or > write at a time, rather than only one process could be using a configuration > at a time. Ok, I guess I need to make that clearer. I thought one implied the other :). Your example is more complex than I had in mind; I'll try to include something like it in the final rationale document. > > Let me ask again; can we choose the general file format now, or do > > you think we need to work on the API more first? > > I think you can pick the file format, sure. If you have "heirarchy of keys > mapped to string values", I don't see much more you need to know for that. But I want _you_ to pick a format, so we can get consensus. Hmm. You said above either is ok; I guess that counts as consensus for the Java property format. -- -- Stephe