FW: GNOME registry.

["Fox, Kevin M" <kmfox bhi010 bhi-erc com>]

I was thinking sorta the same thing. :)

I agree with:
1,
2, if you abstract the data saving method.,
4,
5, verry much so,
6,
9, seems to be like a schema,
and 10

maby 3

dont agree with:
7 would just slow things down/confuse things. environment veriables could be
read by the program itself. (unless he is talking about library envirenment
veriables.... hmm... )

8 global settings might be bad. maby the program could open the "global"
config as well if needed.




> -----Original Message-----
> From:	Matt Gundry [SMTP:mjgundry@fpa-engineers.com]
> Sent:	Thursday, December 31, 1998 2:01 PM
> To:	kmfox@bhi010.bhi-erc.com
> Subject:	GNOME registry.
> 
> I am not subscribed to the GNOME discussion list, or I would have sent
> this message there. Feel free to forward the remainder of the message to
> the GNOME list if you feel it is of interest to the rest of the group.
> 
> I've been following the GNOME registry discussion on the GNOME list with
> great interest. I think a standardized configuration scheme is an
> important feature that has been missing too long from *nix. I believe
> that I may have some useful input into this, unfortunately no useful
> code :(
> 
> A little over a year ago I tried getting an open source CAD app project
> going called FreeDesigner. Before running out of free time to devote to
> the project, I got knee deep into the database and configuration design
> parts. I intended for the configuration management module, named
> ConfigMan, to be a separate library with many of the features that the
> discussion group has mentioned.
> 
> Some of the features I had planned were as follows:
> 
> 1) Key-Data pair style configuration - allow various data types: int,
> float, string, multistring, uuencoded binary...
> 
> 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.
> 
> 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.
> 
> 4) Append/prepend data - string types would allow appending or
> prepending of data as well as override (eg. search paths).
> 
> 5) Configuration change notification via callbacks - nice when changing
> the configuration of a daemon.
> 
> 6) Comment data - allow comments to aid in product documentation or to
> explain an odd configuration.
> 
> 7) Environment variable support
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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
> 
> At Work		mjgundry@fpa-engineers.com
> At Home		mjgundry@primenet.com
> Web		http://www.fpa-engineers.com/~mjgundry/