Re: Config_Files proposal

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

Darren New <dnew@san.rr.com> writes:

> 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. :-)

Yes, that is better.

> > This is a race condition. Suppose two processes happen to start a
> > "flush" operation "at the same time"? Whichever goes last wins.
> 
> That would be simultaneous use. ;-)

Ok, neither simultaneous nor concurrent use is supported.

> > If you feel that makes Config_Files totally useless, I guess we
> > can talk about removing requirement 1 and see if we can come up
> > with locking semantics to fix it. But I'd rather not, especially
> > since the registry and gconf have already done that.
> 
> I don't know that we need locking semantics. I just thought it would be easy
> to apply the changes and merge them appropriately. For that matter, you're
> going to have a similar problem if you have two threads in the same program
> doing this.

Yes, but Ada programmers are supposed to be aware of things like that.
I guess it wouldn't hurt to mention it.

> Certainly it at least has to be made clear in the specs.

yes.

> > > 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.
> > 
> > Ok, I guess I need to make that clearer. I thought one implied the
> > other :). Your example is more complex than I had in mind; I'll try to
> > include something like it in the final rationale document.
> 
> OK. I'm just trying to have ideas about problems before anyone puts a lot of
> work into something, only to find out that the end-users find it too
> unintuitive to use.

Yes, and I do appreciate that.

> Something like "list API" is one thing, since only programmers who
> read the instructions are going to see that. Something like a config
> file where the user can set configurations is another thing. Perhaps
> it's worth having an option to create a lock file of some sort.

Only if we can define it well.

> > But I want _you_ to pick a format, so we can get consensus. Hmm.
> > You said above either is ok; I guess that counts as consensus for
> > the Java property format.
> 
> Yes. I've been pushing towards something where there are minimal syntactic
> interdependencies between keys, rather than something like XML. I'm more
> concerned about precise semantics than about the niggly details of the file
> format, tho.

Ok, I'll put you on the Java side.

-- 
-- Stephe