Configuration API

[Dave Cridland [Home]]

On Wed Apr 28 18:36:33 2004, Lars Hallberg wrote:
> Dave Cridland [Home] wrote:
>> I'd prefer to see evidence that namespace clashes are a real and present 
>> problem, before splitting the namespace like that.
> 
> I think it's an exelent idé, that kan give us a common way to access the 
> config without steping on eachothers toes!
> 

If there's an absolute need, then fine. But I can't see one, unless there are 
pre-existing namespace collisions.

Could one of the KDE folk and GNOME folk give a rundown of the namespace 
heirarchy structure that exists already for each system?

My understanding, which could be incorrect, is that KDE uses a tree with a 
height of 3, corresponding to:

<name>/<group>/<entry>

GConf uses an infinite depth tree, corresponding to:

/<namespace>/<application-name>/<group>/[...]/<key-name>

<namespace> is, for applications, always 'apps', unless we're talking 
> Schemas, which traditionally live in 'schemas'. For system settings, GConf 
uses 'system' and 'desktop', depending on which sort of system we're talking 
about.

Anyone want to correct me?

For comparison, ACAP uses two heirarchies, looking roughly like:

/<dataset class>/<owner>/[...]/<entry>/<attribute>

<owner> can be user/<username>, group/<groupname>, host/<hostname>, or site

Alternately, you can refer to the same data as /byowner/<owner>/<dataset 
>>>> class>/[...]/<entry>/<attribute> - really depending on how you're 
feeling that day.

Either way, being able to access other people's data - if they've allowed you 
to - is extremely funky.

As for possible values, KDE appears to support lots, including expandable 
paths. GConf supports fewer, essentially strings, floats, ints; lists of a 
single basic datatype; or pairs of two datatypes. ACAP attributes support 
only strings, but may be 'multivalued' - which essentially means they may be 
strings or lists of strings. (However, the lists may be reordered on a store, 
so aren't quite the same.)

It seems to me that a short amount of code could examine the top-level name 
in KConfig, and prepend 'apps', 'desktop/kde', or 'system', as needed. I'm 
not suggesting KDE must use GConf here, just suggesting how they might both 
end up using the same namespace. The data models are a little different, of 
course, but I imagine GConf could include support for 'Path' and 'Enum' if 
needs be.

Actually, looking through the documentation for KConfig, the hardest thing to 
solve seems to be its ability to base defaults on the result of a chunk of 
C++. That's pretty wild stuff.

> 
>> Ideally, I'd like to have an application which could be built with 
>> 'native' support for either GNOME or KDE to be able to have identical 
configuration on both, without recourse to accessing the configuration by 
other means.
> 
> Whell, any gnome/kde enabled app dont need to go under gnom.org/kde.org... 
> You kan use yourapp.org to?
> 

Yes, but application-specific namespacing already exists, at least in some 
informal way, in all systems. It must do, almost by definition.

> 
>> Equally, there's a huge amount of configuration data which is naturally 
>> desktop agnostic - email related information, for instance, as well as 
addressbooks and bookmarks if we choose to go that far.
> 
> The stuff will only hapen if we agre on common configuration sematics. 
> Thats cool, and in that case those configs will end up under 
freedesktop.org or another 'standard bodies' namespace.
> 

Doesn't have to be that way, though. And in fact, it makes it worse, 
potentially - unifying two distinct namespaces will always be harder then 
unifying the same namespace.

Apps can have their own chunk for specific settings, but we can also 
namespace key names, for instance - essentially what ACAP does - which means 
that, for example, all email application developers would immediately see 
what each other stored, easily, and it'd encourage sharing.

Dave.