Re: Config_Files proposal

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

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

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

Fair enough.

> > > 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?

Yes, this is bad.

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

Yes. The default is provided again with every call to "read", so it
does not need to be stored.

> I think until you (we) work out the semantics of what's going on,
> implementing multiple bodies is relatively unhelpful to progressing
> the spec. 

Well, I usually find problems with a spec when I get around to
implementing the body. I did these two implementations to see if there
were any problems with the spec that were related to the file format.
I don't think there are.

> Of course, if you're enjoying it and all, that's something else. :-)

I was trying to eliminate one of the variables in the problem. If we
agree on what the file format is, that's one less thing to think about.

I think we are ready to do that, and it will allow people to focus
solely on the spec, rather than on the XML vs ini etc.

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

Let's see. You have two instances of "text_edit", sharing one config
file. That is explicitly forbidden by requirement 1.

So if you want this behavior, you have to use the registry or gconf,
not Config_Files.

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

This is a race condition. Suppose two processes happen to start a
"flush" operation "at the same time"? Whichever goes last wins.

That's why we have requirement 1. Config_Files don't do this.

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.

In general, I suggest that there are other ways to fix an apparent
need for concurrent access to config files.

For the specific case of a text editor, you can use a text editor that
supports multiple documents; that provides automatic sharing of config
file settings between XYZ.adb and XYZ.ads.

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

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.

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

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.

-- 
-- Stephe