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 13:04:43 PST Path: archiver1.google.com!news2.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: <3D10E046.E604231D@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> <3D10B6B1.AFE9D4E8@san.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 19 Jun 2002 19:48:58 GMT NNTP-Posting-Host: 66.75.151.160 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1024516138 66.75.151.160 (Wed, 19 Jun 2002 12:48:58 PDT) NNTP-Posting-Date: Wed, 19 Jun 2002 12:48:58 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:26433 Date: 2002-06-19T19:48:58+00:00 List-Id: 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. > > 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? > > 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. I think until you (we) work out the semantics of what's going on, implementing multiple bodies is relatively unhelpful to progressing the spec. Of course, if you're enjoying it and all, that's something else. :-) > 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. 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. > > 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. > 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. -- 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.