Re: Panel's GConf usage

[Havoc Pennington <hp redhat com>]

On Mon, Feb 24, 2003 at 04:25:12PM -0500, Ettore Perazzoli wrote: 
> What we really want, I think, (and I don't know if it's been discussed
> before somewhere) is some way to define "structs" of data with default
> values, and define an entry in the database as a list of those structs. 
> And of course, there should be an API to modify the structs.

As a total tangent - I'd generally feel that "maps" or "hashes" are a
better model than structs, since structs seems to involve a lot of
ABI/typesystem stuff and inevitable IDL, while "maps" could just be a
property bag type of interface where you get fields by string
name. "dynamic structs"?

> Also, elements in the list should get an automatic ID so you can update
> them without manipulating the list directly -- and that should help take
> care of the race condition problem.
> 
> Actually, this sounds like it wouldn't be too difficult to build on top
> of GConf, doesn't it?

If you have an ID for each item in the list, that starts to sound not
very different from using a directory as your list and having a name
for each subdirectory, no?

Assume GConfChangeSet was made genuinely atomic, and there was an easy
or built-in way to monitor the list of stuff in a directory (rather
than using something like
/apps/gnome-terminal/global/profile_list). That is, what if the
equivalent of /apps/gnome-terminal/global/profile_list were maintained
automatically, so you could just subscribe to get notifications on a
directory listing.

In any case it might help clarify our thinking on this topic if we
make a list of the differences between a directory, and a
map/hash/propertybag. Both are maps from strings (names) to values.

 - Given transactions, multiple changes to a directory could be made
   atomic, so there's no difference there.

 - However, items in a directory have no inherent ordering, while
   items in a list do. (You could also imagine changing this, 
   gconf doesn't really *have* to follow UNIX filesystem semantics 
   here.)

 - Directories can't be placed in a list, only their names. Of course,
   neither could maps at the moment since gconf doesn't currently
   allow recursive datatypes.

It's worth thinking through how much complexity is added by allowing
recursive datatypes. I'm not sure how bad it would be. It definitely
makes all code dealing with GConfValue a good bit harder to write and
verify, but conceptually isn't *that* bad.

I don't know what implications this stuff has for LDAP etc. storage;
Kris could maybe comment on that.

The other question is how much of this you want on the
protocol/storage level (gconf proper) and how much should be
convenience wrapper API on the client side, or hints for gconf-editor.

In all this, I'd like to keep the general complexity level of gconf
for both gconf maintainers and app programmers not *too* much higher
than it currently is. If it gets much more complex I don't think we'll
ever figure out the semantics or be able to make it stable.

Havoc