Please remember: Even though I write these lines as if cfgd already exists, it is still in planning phase. So this is merely a collection of ideas.

• cfgd helps application writers, system administrators and end users to manage application configurations.
• Only cfgd knows the exact location of configuration files.
  Proposed location and structure:
  

  	|--/etc/cfgd		All configurations are in this directory
  	|    |--MyApplication	
  	|    |      |--default	System default configuration
  	|    |      |--willy	Configuration of user 'willy'
  	|    |      |--host2	Configuration for host2 (another host)
  	|    |      |    |-- default
  	|    |      |    | ...
  	|    |--MyApp2
  	|    |    |-- ...
  	

  An application just asks cfgd (through libcfg) for its configuration, eg. "GetConfig (MyApplication);". cfgd will search in it's directory for the appropriate configuration, will merge system-default and user-configuration (or will ask another cfgd to do so in a networked environment) and supply the configuration ready-to-use to the application.
• Every imaginable application should be able to maintain it's configuration with cfgd. Therefore the configuration file format must be flexible enough to allow administration of every possible configuration. The applications are not directly confronted with the config files themselfes, i.e. they don't know anything about the actual config-file-format. They access their configuration through the API (libcfg) in an programming friendly way.
• The actual configuration file format I choose (for now) is XML. The files are more then simple "var=value" containers. They store meta information as well. That is, a system administrator can make some values of the configuration e.g. 'read-only', so users can't overwrite them in their user specific configuration. In the XML files there are "predef" fields, allowing variables only to contain values defined in them. Value type information (e.g. 'integer') is also imaginable, even though not implemented at all yet.
• Administrators and users modify configurations with a specialized configuration application ('cfg', 'xcfg', 'gcfg' ... something like that). This application presents the configuration in a user friendly way, providing additional meta information like 'descriptions', 'comments' etc., too. Neither administrators nor normal users have to fiddle around with the (xml-) configuration files directly.
• An application is normaly not interested in all the meta information stored in the actual config file. So the protcoll used between cfgd and an application can be optimized to ship only the configuration values without the meta information.
• cfgd should enable administrators to build 'configuration hosts', a cfgd host which administers configuration for a whole site. Thus an administrator can manage configurations on one single host for a large number of hosts. Therefore there must be a reliable way to authenticate users with cfgd, so cfgd knows for sure which user is accessing a configuration. Users and hosts must have something like a 'net-identity' and the data exchange between two cfgd's must be encrypted.
• cfgd should be able to notify other cfgd's and applications if a configuration has changed. So some kind of event-handling must be implemented.