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 09:51:34 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!twister.socal.rr.com.POSTED!not-for-mail Message-ID: <3D10B6B1.AFE9D4E8@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal References: <3D0FAC67.A4861809@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 19 Jun 2002 16:51:33 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1024505493 66.75.151.160 (Wed, 19 Jun 2002 09:51:33 PDT) NNTP-Posting-Date: Wed, 19 Jun 2002 09:51:33 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:26398 Date: 2002-06-19T16:51:33+00:00 List-Id: 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. > > That said, there's some things missing from the spec: > > > > 1) When you read three config files off the path, change a value that was in > > the second one, and write it out again, where does it get written? > > I tried to answer that in requirement 10, but I can see it isn't very > clear. > > The intent is that only one file be writable, and that is where all > values are written. > > For example, if you open ~/.myconfig (writable), /usr/local/app/config > (readonly) and /etc/app/config (readonly), then any values you change > are written to ~/.myconfig. What about values you don't change? What about values that you change back to match what's in /usr/local/app/config? What about values you don't change but which came from ~/.myconfig? 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, 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. > > 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. > Hmm. Now I think we need the queries "what file was this value read from" > and "what file will this value be written to". Something close to that, yes. :) Oh. One other question. How often are the config files read? If someone changes a config file while I'm running, do I see the change reflected? 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? I think if you're not careful, there's going to be very unintuitive behavior. > but not in the visible part of the spec). Since the same effect can be > accomplished via numbered keys, I don't think it's worth pursuing at > this time. Fair enough. > 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. > Once again, thanks for your insightful comments. Hey, it's fun. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug.