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-28 20:01:12 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!cox.net!p02!news2.central.cox.net.POSTED!53ab2750!not-for-mail Message-ID: <3D1D22BB.7000305@telepath.com> From: Ted Dennison User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, 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> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 29 Jun 2002 03:01:10 GMT NNTP-Posting-Host: 68.12.51.201 X-Complaints-To: abuse@cox.net X-Trace: news2.central.cox.net 1025319670 68.12.51.201 (Fri, 28 Jun 2002 23:01:10 EDT) NNTP-Posting-Date: Fri, 28 Jun 2002 23:01:10 EDT Organization: Cox Communications Xref: archiver1.google.com comp.lang.ada:26786 Date: 2002-06-29T03:01:10+00:00 List-Id: 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. > 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? Probably the way to think of this of this problem is in terms of revision-control systems. We could only allow files to be updated with "delta" operations. But even then, you have the old revision-control problem of merging conflicting changes. I've yet to see a merging algorithm that didn't have situations that require human intervention. However, with our file format we probably couldn't detect these conflicts, so we'd just be back to the problem of wiped-out changes (but with a much smaller window for the wipeout to occur). This is sort of like an unlocked checkout in revision control systems. I think this is roughly the solution they used for the emacs ada-mode problem. 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.