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-20 13:03:06 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail
From: Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
Newsgroups: comp.lang.ada
Subject: Re: Config_Files proposal
Date: 20 Jun 2002 16:00:03 -0400
Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov)
Message-ID: <u1yb1u3ek.fsf@gsfc.nasa.gov>
References: <uwuswy0qr.fsf@gsfc.nasa.gov> <3D0FAC67.A4861809@san.rr.com>
 <uu1nzw8n3.fsf@gsfc.nasa.gov> <3D10B6B1.AFE9D4E8@san.rr.com>
 <uznxrun8p.fsf@gsfc.nasa.gov> <3D10E046.E604231D@san.rr.com>
 <uadpqujxc.fsf@gsfc.nasa.gov> <3D1204B5.4620F160@san.rr.com>
 <3D1215A8.719D39C5@nbi.dk>
NNTP-Posting-Host: anarres.gsfc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: skates.gsfc.nasa.gov 1024603662 7356 128.183.220.71 (20 Jun 2002
 20:07:42 GMT)
X-Complaints-To: usenet@news.gsfc.nasa.gov
NNTP-Posting-Date: 20 Jun 2002 20:07:42 GMT
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Xref: archiver1.google.com comp.lang.ada:26515
Date: 2002-06-20T20:07:42+00:00
List-Id: <comp.lang.ada>

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Darren New wrote:
> > 
> > Stephen Leake wrote:
> > > Let's see. You have two instances of "text_edit", sharing one config
> > > file. That is explicitly forbidden by requirement 1.
> > 
> > Then requirement one should speak of concurrent use, rather than
> > simultaneous use. :-)
> 
> This discussion made me think of how my e-mail client works
> (typically, I have five running instances of it). It somehow
> keeps an eye on changes to the configuration file, so if one
> instance has saved a changed configuration, the other
> instances will (when they happen to feel like looking at the
> configuration file) complain, and ask if I want to use the
> in-memory or the disk configuration.
> 
> I don't know how trivial the implementation of this feature
> is, but just keeping a copy of the time stamp of the file
> with the in-memory configuration would help a bit, although
> one also could use a file check-sum.

Yes, there are ways to do it. 

I think we have three choices here:

1) Simply forbid simultaneous and/or concurrent access to a single
   config file (as the requirements currently state).

2) Allow simultaneous and/or concurrent access, and define the
   behavior to be similar to Jacob's email program.

3) Allow full concurrent access to keys, the way the registry does.

I chose 1) originally to keep things simple, and because it meets my
needs.

I think we should avoid 3), because it's way too hard (you get into
"change notification messages"), and because the registry and gconf
already do this nicely.

I could go for 2), if enough people think it is important.

Or we could agree to do 2) later, after everything else.

-- 
-- Stephe