Re: gnome-config problems

[Marc Ewing <marc redhat com>]

Tom Tromey <tromey@creche.cygnus.com> writes:
> The reason I think there should be just one API is that I want the API
> to insulate me from details like files and directories.  As an
> application writer, I don't much care if the data is stored in flat
> files or if it is stored in one monster database.  I do care that the
> API I use presents the right abstraction.  If we ever decide to move
> to a database, knowledge of things like directories (even as an
> abstract concept) is going to hurt us, I think.

I agree.  With the current "path" scheme, files and directories
are referenced directly, and the section/key are thrown in the
mix as well.  All this makes for a complicated syntax, and one
that will be difficult to evolve.

> >> * I'd really like to have a way to set/get a vector of strings.
> 
> Miguel> Oh, propose an API and I can code that :-)
> 
> void gnome_config_set_vector (const char *path, int argc,
> 			      const char * const *argv);
> void gnome_config_get_vector (const char *path,
> 			      int *argc_ret, char ***argv_ret,
> 			      int *def);
> 
> I'm not particularly enthused about the name "_vector", but I don't
> have a noticeably better suggestion.

How important is it to have the config files text based (as in 
editable with a text editor)?  If I offered a solution along the
lines of a "database" (as referenced above) that could hold
integer, string, and binary data, and arrays of those, along with
command line utilities to query and modify them, would that be
acceptable?

I ask because we already have code that does most of this.  It
handles all the marshalling of the data, byte order, etc, and
presents a very easy interface for programming.  Extending it
with new data types is trivial and can be done without breaking
any existing binaries, sources, or config databases.  It also
has builtin transparent support for i18n when accessing strings
or string arrays.

If the tradeoff sounds OK, I can probably have this code working
in about a week, along with a compatibility layer for gnome-config.h.

-Marc