Configuration API

Thomas Leonard tal00r at ecs.soton.ac.uk
Tue Apr 27 17:59:22 EEST 2004


For the configuration system, are we agreed that we need a library API?

Without it, the system seems too inflexible. Eg, we either require every
application to support remote database access, or we can't support storing
configuration in remote databases.

If we make an API, then people can get started writing backends for it.
Eg, someone could make a gconf backend and all programs using the API
would get their settings stored using gconf. Someone else could make a
Linux Registry backend, or a D-BUS daemon, etc.

The API would have to be desktop neutral, support getting and setting
values, and notification (if the backend supports it). We have some good
example APIs, such a gconf's (and I guess the authors of those systems are
the best people to suggest something).

We have to provide a way to work notification into the application's event
loop (something desktop-specific APIs haven't had to worry about).

To get discussion started, perhaps people could criticise this quick
sketch:

  /* Load the appropriate backend for the given profile. The backend to
   * use and its settings are read from $XDG_CONFIG_DIRS/profiles/<profile>.
   * Two well-known profiles are "system" and "user".
   */
  FdoConfig *fdo_config_open(char *profile);

  /* Finish with the handle */
  void fdo_config_close(FdoConfig *config);

I guess we support a few basic types...

  char *fdo_config_get_string(FdoConfig *config, const char *key);
  void fdo_config_set_string(FdoConfig *config,
  			const char *key, const char *value);
  /* (and likewise for _int, _double, _bool, _any) */

Can we efficiently get/set large numbers of options at once?

  fdo_config_set_many(config,
			type, key, value,
			...
			NULL);

Perhaps we should use option objects instead?

  FdoOption font_name, line_spacing;

  fdo_config_register_string(config, &font_name,
			"freedesktop.org/default-font");

  fdo_config_register_int(config, &line_spacing,
  			"openoffice.org/line_spacing");

  name = fdo_config_get(&font_name);

(the first get call can request all the values at once)


Should notification FDs be per-profile, or just one for the whole
library?

  int fdo_config_get_notify_fd();

  /* Call this whenever fdo_config_get_watch_fd() is ready for reading */
  void fdo_watch_fd_ready();

How do you register interest in a particular option changing?

  void fdo_config_add_notify(FdoConfig *, char *pattern, FdoConfigNotify *);
  void fdo_config_remove_notify(FdoConfig *, char *pattern, FdoConfigNotify *);


I suspect there are people here who've thought about this a lot more than
I have. What are your plans?


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1




More information about the xdg mailing list