One very time consuming task for developers is to provide a way for the users
to configure his application. There is no standard configuration file format,
configuration files are spread throughout the system and the users have to
read a lot of documentation to know which values to set or unset.
The programmer of an application has no API he can use and so he has to write
a (in most cases simple) configutation file parser for himself which leads to
the fact, that every little application has its very own config file format.
cfgd tries to provide a unified way to access config files which is flexible
enough to satisfy all needs (not a simple task).
To archive this there are a few things to be met:
-
provide exactly one place for config files.
cfgd is planned to handle all configurations for
every applications. the application itself should not need
to know where it configuration actually comes from. it simply
asks a local cfgd and get its configuration from the daemon.
this is work to be done.
-
provide an API for every programming language.
'libcfg' is my first attempt for this, providing an API
for the C language (and consequently C++, although C++
can have it's own API). all the application has to do in
order to get its configuration is to call a couple of
functions from this API.
-
provide an application for manipulating configurations.
a user should not need to know where config files are kept,
nor what kind of file it is. a user simply wants to alter
a configuration and should therefor have a unified
application which permits alteration of a any given
configuration.
'cfg' is planned to be a text-frontend to manipulate
configurations. this is work to be done.
-
the software should have a very liberate license in order
to allow everyone to use it without any reservation.
therefor the 'cfgd' package uses the very liberate MIT-license.
-
the whole software package should be easy to install and should
not rely on any previously installed packages. all needed parts
should be shiped with the 'cfgd' package.
|