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-19 11:43:20 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: 19 Jun 2002 14:39:18 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3D0FAC67.A4861809@san.rr.com> <3D10B6B1.AFE9D4E8@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 1024512423 12195 128.183.220.71 (19 Jun 2002 18:47:03 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 19 Jun 2002 18:47:03 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:26418 Date: 2002-06-19T18:47:03+00:00 List-Id: Darren New writes: > Stephen Leake wrote: > > That isn't what I meant to say :). The API _is_ orthogonal to the file > > format. > > I don't think the API covers everything you'd want yet. Ok. Do you think that prevents us from agreeing on which file format to go forward with? It's a pain maintaining two example implementations. The stuff we are talking about here is totally independent of file format. > 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. > 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). Perhaps also a total "erase", which would discard all changes. > What about values you don't change but which came from ~/.myconfig? Hmm. Good point. I guess all values from a writeable file must be written, not just changed ones. > There's no obvious place I saw in the .ADS that shows multiple file > names being offered for reading, such that they'd be linked in any > way. Yes, that is not implemented. > > Yes, but any values the user changes will be written to the local > > file. Same example as above. > > OK. That isn't clear from the docs. At least not to me. Right, it needs to be added. > > > 3) If you enable #2, and then the user changes her email > > > address, does it also store back the mail server address, > > > thereby preventing the administrator from changing it? > > > > Hmm. I was going to say "no, the user did not change that value". That > > is my intent. But my draft implementation does not follow that intent; > > it writes all the values to the writeable (local) file. > > > > I'll declare that implementation broken, in this respect. I guess I > > need a "value changed since read" marker, and only changed values get > > written. > > Still not good enough. If I change the user email address this session, > write it out, then change the window position next time, I don't want to > lose the email address when I write it. > > I think you need to keep track, for each value, what file it was read from > and whether it changed. Then when you write it out, write out any values > that have changed as well as any values that originally came from the file > you're rewriting. Yes. > Oh. One other question. How often are the config files read? When you call "open". > If someone changes a config file while I'm running, do I see the > change reflected? We explicitly rule out multiple parallel processes accessing the same files. So that's erroneous usage, and you may format your hard disk :). > What if I run two copies of the app at once, one of which I use to > configure a bunch of stuff, then write it back out, and the other > which I move a window but don't change anything else. Does it reread > the "changed" file, make the updates, and write it back out? Don't do that. 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. Or, if you really want one value shared among processes, use the registry, since it is designed for that. > 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. > > Hmm, I'm wrong. There is a requirement to return "a list of keys". I > > guess that will be a list of strings. When I implement that, I'll > > think about this issue again :). > > I'd think an unconstrained array of strings would be best there. Of course, > if it's part of Grace, you have th elists. Ah. I guess I can rely on other Grace components. Good point. > > Once again, thanks for your insightful comments. > > Hey, it's fun. :-) Less fun from this end :). But still Ok. 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? -- -- Stephe