Re: config system thoughts

[Miguel de Icaza <miguel gnu org>]

> Must be able to store int, float, string. Also need a "record" or
> "struct" type, to store something like a printer; record has a fixed
> set of names and fixed types for the value at each name.  There are
> four list types, containing each of the four basic types.
> 
> Should lists of lists be allowed? Probably so, since you can do this
> via a record type anyway (a record containing a list) so it may as
> well be allowed in a non-ugly way.

I would like to suggest two things:

  1. To provide an XML backend.
  2. To provide a tree-like API for accesing the information.

Here is why:  The main complain people had with the simplistic
gnome-config stuff we had was that everyone tried to store complex
data structures so they resort to all sorts of hacks to get that into
the config space we had defined.

You need to provide at least a tree and an API for walking this tree.  

> I think no. If you have simply two levels, a per-vendor and
> per-application namespace, plus lists/records, I think that's
> fine. And it reduces the complexity of backend implementations and the
> API quite a bit.
> 
> So every actual key-value pair would be stored under
> /vendor/appname/key. Remember that values can be "records," giving you the
> equivalent of a "section" in gnome-config.

This is exactly the mistake of the existing API.  It does not enable
people to store any interesting data structure.

The gnome-xml API is pretty good.  If you wrap that (so that you could
choose, say, an LDAP or Netinfo backends) you would get all you need.

Perhaps a simplification on the XML API would do it (ie, you do not
need all of it).

> On the implementation side, backends will probably be implemented as
> loadable modules.

Well, there are many things here that need to be discussed:

      1. People abused the older gnome-config to share information
         between applications (which lead to the
         "stat-the-file-everytime-to-see-if-someone-has-touched-it
         and-then-reload" hacks.

	 Be prepared for this.

      2. If you want to provide "listeners" so applications can get
         "notifications" on changes on the config stuff, you probably
         will need a separate process for managing this.  

      3. You do not want to embed into applications the "backend"
         locator, it should be something the sysadmin or some GUI tool
         configures. 

> This is the hardest thing to implement, it will require some kind of
> daemon and there are serious security issues to work out. This is the
> main problem I'm not sure how to approach.

Not really.  Just make it a per-user daemon.

> gnome-config should remain unchanged for backward compatibility and
> stability; apps would gradually migrate to the new GConf API. I don't
> think it's feasible to implement gnome-config in terms of this more
> powerful system without breaking the more powerful system.

Agreed.

Miguel.