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-07-01 13:58:59 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal Date: Mon, 1 Jul 2002 15:58:50 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3D0FAC67.A4861809@san.rr.com> <3D10B6B1.AFE9D4E8@san.rr.com> <3D10E046.E604231D@san.rr.com> <3D1204B5.4620F160@san.rr.com> <3D1215A8.719D39C5@nbi.dk> <3D123852.1040508@san.rr.com> <3D1289D2.9090107@telepath.com> <3D134669.5070000@san.rr.com> <3D1D22BB.7000305@telepath.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:26801 Date: 2002-07-01T15:58:50-05:00 List-Id: Ted Dennison wrote in message <3D1D22BB.7000305@telepath.com>... >OK. I think I'm finally getting the problem here. This is my old issue >with the emacs ada-mode case exceptions file from two years ago, come >back to haunt me. :-( > >Randy Brukardt wrote: >> I think these are silly. I've always been dubious of this package, and >> if this is the result, then there is no reason to bother, because it >> would be totally useless. > >I think that's a bit extreme. At most, I think one could say that it >would not make for a good solution in some cases. In particular, it >would be a problem any time the program itself is both reading and >writing config files, *and* there is the possibility of multiple copies >of the program running simultaniously. Remember that we must include >networked installations of a program under this umbrella. > >This situation includes just about any desktop user app (eg: an Ada text >editor). However, it happens to exclude every situation where I've found >myself using a configuration file in the past (generally systems >software). So I think calling it "useless" is overstating the case, >possibly to the detriment of the point. Well, "useless" is a bit extreme, but not much. You say that pretty much all desktop apps couldn't use the package if Requirement 1 remains. Moreover, most embedded applications can't use the package, because they don't have a file system. So that leaves how many applications? Let's be generous and say 10%. Why should we bother with a "standard" package that can safely be used in only 10% of the applications? That hardly needs to be standardized! >> Summary: Requirement 1 has to go. For this package to be useful, it has >> to make it easy to create bullet-proof configuration files, and more > >I should point out here that the solution for this problem with Emacs >ada-mode case exceptions is not "bullet-proof" either. However, it was >close enough for me (the original complainer), and I have yet to hear >anyone call ada-mode's case exceptions "useless" since then. > >Say we do remove requirement 1. What do we replace it with? One >possiblity is "nothing". But in that case we will make a portable >reference implementation that doesn't bother with this case, nearly >every vendor will just use the reference, and you will still not have >this situation handled. > >So what's the alternative you'd like? In other words, how does one solve >this problem so that its impossible to loose changes due to simultanious >edits? You can't exactly (and probably shouldn't in every possible case), but you can adopt rules that make it unlikely that trouble will occur. I suggest: 1) If two applications write different, unrelated keys in the same file, both changes will be reflected, and nothing else will be changed. 2) If an application writes a group of keys, it needs to be possible that the application can insure that the entire group is updated as a set. These the first rule means that the only time a simulateous edit will be lost is when two apps write the same key. There isn't much that we can do about that. The second rule means that an app can insure that some consistent set of keys is written, even if another app is trying to write the same keys. (Imagine a set of keys representing a screen position, getting written at shutdown of a bunch of copies of an editor. We don't care which position is saved, but we certainly want to insure that a single complete position is saved, rather than parts of several. >Another possibility would be some kind of explicit "edit" call that >locks the file and reloads everything, and an "end edit" call that saves >and unlocks it. But the client would still need to be very careful to >display the read-in configurations for editing, not the ones that the >program read in when it started. This is the "locked check-out" >approach. The problem with this approach is that the locker may go AWOL, >holding up everyone's changes for an indefinite period. This can be mitigated by using a controlled object "lock" for editing. Then, if the locking app is aborted or has an unhandled exception, the lock will get freed. That prevents program bugs from keeping the file locked. (You'll still need some way to deal with OS termination of the application's process; probably the lock will have to have a time limit on it.) Randy.