I agree that this is a good and worthwhile idea.
May I suggest that we start defining an API and a standard configuration
library, and start encouraging application writers to migrate to the new
library?
Design notes:
1. The library should be licensed under LGPL, because we want it to
"infect" also non-free software projects.
2. The implementation should provide for a way to call back the
application's legacy configuration mechanism, as another option (in
addition to configuration files, configuration daemon, etc.). It is up
ot the application maintainer to interface between the legacy
configuration mechanism and the library's, but we'll try to make it as
painless as possible for him. This will make it easier for
distributions to migrate to the new configuration scheme.
A thought for a design for the new configuration mechanism (for systems
which can afford the big footprint):
- Environment variable setting the global configuration mechanism (file or
daemon).
- The global configuration mechanism shall specify, for each application,
the application's configuration mechanism to be used.
Thus, some applications will be configured from files. Others will be
configured from associated configuration daemons.
- The mechanism shall provide for configurability in the package level
(for example, some configuration options will apply to all X-Window
applications; others will apply to all Gnome applications, etc.)
together with overridability for individual applications.
I wonder whether the following paradigm will be powerful enough to cover
all cases:
An application will treat configuration information as an hash
(associative array). With each key (an arbitrary string), one could
associate one of the following:
- scalar integer/real/Boolean/string value
- array of values having the same type
- another associative array
The other complications (such as allowing applications to share
configuration data) shall be taken care of by designing appropriate
conventions for the key strings.
To access a configuration option, the following API is needed:
- retrieve_config_value(const char *key); to be overloaded with the
possible types of values.
- set_config_value(const char *key, void* value); to be overloaded, too.
Some mechanism is needed to handle tree-structured configurations (where
the value of a configuration value can be another associative array).
- register_config_change_callback(const char *key, func callback);
[where func has been typedef'ed to be a suitable function pointer]
This will register a callback into the application, to be called each
time anyone from the outside will change the registered configuration
option.
On Mon, 13 Jan 2003, Oron Peled wrote:
> I do accept your observation, that in *many cases* there was no
> good reason to invent yet another poorly engineered config
> mechanism. I would suggest though, that a more realistic goal
> should be to *minimize* the number of different config types.
> For example:
> - A linear key=value pairs (e.g: INI files)
> - Hierarchic config (e.g: static XML)
> - Dynamic config (e.g: Registry/gconf)
> - Inherited config (e.g: environment variables)
> - .... where do I fit Xresources?
> - ... others
> So we may try to converge to some "best-of-breed" API in each
> category. Some categories may even need alternative selection
> due do special constraints:
> - On small footprint systems you trade flexibility for
> footprint.
> - Some maintenance modes (e.g: single user) may force you
> to manual config, so you cannot depend on running config
> deamons (gconf, *SQL, etc.)
> So you may want both "full-blown" API and a "minimal-API" for
> the same category (similar to glibc and dietlibc).
--- Omer
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
