Re: FW: GNOME registry.

["Joshua R. Prismon" <josh narf com>]

>> 1) Key-Data pair style configuration - allow various data types: int,
>> float, string, multistring, uuencoded binary...

I think that their does need to be some key pairing, but not in the
typical sense of the limited keys that the registry uses. I think
that Key's can be directories. 

>> 2) ASCII flat file based - allow recovery with vi. The application is
>> not aware of the storage method, however. The app merely supplies a name
>> and version to the library.

Their needs to be a ASCII backend. It should not be limited to that. Parsing
is _slow_. 

>> 3) A three (more?) tiered approach to configuration - local system at
>> the lowest, followed by network, and then user. Higher levels
>> override/modify lower levels. Flags give administrator control over
>> which keys can be modified at higher levels.

Yuck. How bout just layering elements over each other. (Their should
not be any need for a permissions model. If a program only wants the
root to modify something, so be it. Don't let the user put their own extensions
on top). 

>> 4) Append/prepend data - string types would allow appending or
>> prepending of data as well as override (eg. search paths).

Good idea, if you have large keys.

>> 5) Configuration change notification via callbacks - nice when changing
>> the configuration of a daemon.

Good idea. 

>> 6) Comment data - allow comments to aid in product documentation or to
>> explain an odd configuration.

Good idea. (fits with the entire idea of a single interface object). 

>> 7) Environment variable support

BLECK!  The enviornment has allready been kludged to high Hell. 

>> 8) Special library support - shared libraries get app specific configs
>> as well as global settings if needed. App specific configs act as a
>> fourth tier.

Fits in the the back end. (far less tiers ;-)

>> 9) Dialog description language - each app would include a dialog
>> description file that would define a dialog for editing various
>> configuration values. This file could be used by the application at
>> runtime and/or a standalone configuration editor (ala regedit on roids)
>> to create a meaningful configuration interface for the user.

We could do this thru the XML structure. I don't think there is any need
for a program to describe exactly how to represent it. 

>> 10) Configuration upgrade/migration support - allow a new version of an
>> app to easily load an old configuration file without altering it -
>> basically config versioning I guess.

Do we need versioning? (ie, extra fields that get added are not looked at 
anyways). 

>> I hope you find some of these ideas useful in designing/discussing a
>> configuration library. I wish I had some code to offer you, or time to
>> implement some of these features, but I don't. Good luck.
>> Matt Gundry, EIT, Project Engineer

Thanks for the suggestions...