Configuration API

[Lars Hallberg]

Sean Middleditch wrote:

>On Thu, 2004-04-29 at 08:56, Thomas Leonard wrote:
>  
>
>>>Some apps need to store complex data types, for example.  (think
>>>structs, or maybe just associative arrays.)
>>>      
>>>
>>Isn't this normally done with the key names directly? Eg, rather than:
>>
>>	/net/proxy = {ftp: "ftp-proxy.com", http: "http-proxy.com"}
>>    
>>
KDE can acces the config like abowe (at least as a backwards compability 
feature during a transmission period) while everyone else sees it as:

/net/proxy/ftp: "ftp-proxy.com"
/net/proxy/http: "http-proxy.com"

>Then we need a way to scan all keys under a particular path.  I.e.,
>"what structs/subdirs are under /panel/objects/"
>  
>
I asume that, ether a function to get the children (DOM like) or some 
pseudo key (read only) giving a list of children, like:

/net/proxy/_children -> ftp, http

Anyway, ther shuld be some way to scan a tree, an preferably a way to 
get description of keys if available, and get/set comments. So a 
'stupid' regestry like editor is possably (Nice contextawere GUI is 
better, but simple, stupid stuff for fallback is often necesary, and 
nice for fast job when You know exactly what to do!).

>No, because that makes administration hell.  That was one of the
>problems with LR.  If you don't have types that support what we need,
>each app will invent its own file format inside the key values, which
>defeats the entire purpose of having a common API.
>  
>
Agree. The should be datatypes. They *may* be strings, but color shuld 
be in *one* defined format, regardless of how the underlaying backend 
stores a color!

Possably ther shuld be a way to fetch/set compleet subtrees as a 
standard defined XML.

Probably a stupid idé, but just a foght - defining a XML format for 
representing the config, then the API can be a distributed DOM to a 
virtual XML document describing the whole systems config. Forget I said 
that :-/

>For one, you can no longer monitor or individually change particular
>bits of data that are stored in those specially encoded XML/whatever
>values.
>
>For two, admins then need to learn many different formats, you need to
>wirte all sorts of parsers to handle these formats, etc.  Tons of
>complication put on both developers and administrators for no reason
>given that the configuration system can do it on its own and save
>everyone the pain.
>  
>
>>>Is this API going to be only actual preferences, or do we also want to
>>>store application state (window position and such) and data (recent
>>>files?) as well?  If yes, the API needs to be able to handle the
>>>oddities of each.
>>>      
>>>
>>It may be that the 'ultimate' config system would be a filesystem with
>>efficient storage of small files (reiserfs), automatic backups (svn),
>>atomic commits of multiple files, networking, stacking (unionfs), change
>>notification (distributed dnotify?) and user-space hooks (fuse) for
>>ultimate flexibility.
>>
>>However, we probably need to build something a bit simpler at first ;-)
>>    
>>
>
>Not so much simpler as something that actually exists.  The features you
>listed above do not exist on many platforms, and even Linux doesn't
>support those universally.  I for one won't use ReiserFS given its tons
>of actual problems that make efficient storage of small files
>worthless.  (Look at the current Reiser4 non-sense - needing special
>syscalls to even handle POSIX attributes?  screw that crap.)
>
>  
>
>>I guess what we actually want is an API that:
>>
>>- Lets us implement all the functionality of the GNOME and KDE systems
>>  that is presently used/needed.
>>
>>- Can be extended in the future.
>>    
>>
>
>Better we get it right the first time.  Otherwise we're going to get a
>system up, that's going to have tons of problems "that can be extended
>around later" and that's never giong to happen. GConf was an experiment
>that has stuck us with production systems with a few problems.  Or look
>at the current X discussions: it was always intended to be
>improved/extended, yet it's take some, what, 15 years to do it?
>  
>
Think it needs to be extandable (see other mails about splitting it in 
interfaces). But that does not men we shuld not try to make it good from 
the start!

>>>How will the API handle differences between per-user and per-machine
>>>settings, system-wide and session-wide settings, and so on?
>>>      
>>>
>>I think that ideally that wouldn't appear in the API at all. ie, the
>>session manager asks for the key 'freedesktop.org/window-manager', and
>>it's up to the backend to get a value appropriate to the current
>>user/machine/system-wide-defaults.
>>    
>>
>That sounds good from an app point of view.  But say I want to write a
>graphical configuration editing tool for administrators?  Should it be
>backend specific, or capable of using all backends and thus configuring
>th eper-machine/per-user/etc stuff?
>  
>
I think the API should provide both ways! Possably:

user/freedesktop.org/background/picture
host/freedesktop.org/background/picture (readonly to ordinarly users)
dist/freedesktop.org/background/picture (probably read only always)

and just:

/freedesktop.org/background/picture

To get the right for curent context. But the later *might* be convinence 
functions built *on top* of the API, don't know. But given that the 
cheems might need to be different for different apps, if we want to 
suport all existing apps (not to change them, but to make it passable to 
configure them) it posably should be in the API and implemented in the 
backend!

Think gnome and kde (or anyone) shuld be free to implement ther own 
background  setting under ther own domain name. I as a user might want 
diferent background if I run KDE or Gnome! But if the KDE seting is 
unset, the freedesktop one should be used. Realy, if the freedesktop 
user seting is set, the KDE host seting should be overidden. But this is 
more of an 'internal' problem for Gnome and KDE I think.

/LaH