Re: config system thoughts

[Havoc Pennington <hp redhat com>]

On Tue, 20 Jul 1999, Miguel de Icaza wrote:
> 
>   1. To provide an XML backend.

Good.

>   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.  
> 

Do you want lists of lists, or a hierarchical namespace, or both? Do you
think struct/record types would make it nicer to store complex structures?

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

Well, my idea was to offload the structure from the namespace to "record"
and "list" and "list of list" types, which are more structured than the
namespace because they're typed. I don't know if this will fly.
 
>       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.
>

This is another use for the notifier/listener thing. If there's any
polling it would be only a single daemon process doing it.
 
>       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.  
> 

Exactly, which is a big can o' worms.

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

Right, there would be a tool that did this. Apps would call
gnome_get_the_conf_thingy() and it would appear to be a single
uncomplicated namespace. The API from apps point of view would be very
simple.

> > 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.
> 

Hopefully that will work...

Havoc