DConf Database Suggestion

[Dave Cridland]

On Mon Apr 11 11:04:19 2005, Jamie McCracken wrote:
>> Moreover, I still don't see how that allows the administrator to 
>> force a particular email client on a user whilst allowing them to 
>> change their desktop background.
> 
> Okay let me clarify:
> 
> 
Yes, you've clarified, but not in a way that clarifies how SQL's 
GRANT/REVOKE actually help here. It's quite possible I'm just being 
unbelievably stupid, but I'd greatly appreciate knowing how.




>> Finally, I think this sort of storage-level fiddling is largely 
>> similar to telling UNIX admins to ignore the package manager. Yes, 
>> it's possible, but it's rarely a good idea.
> 
> Well its no different for LDAP which the KDE folks would like. (I 
> actually think remote admin is a core requirement for DConf and its 
> a significant part of the "lets make sure DConf is better than what 
> we currently have")
> 
> 
No, indeed, it's no different from LDAP, or any local-only system. 
That doesn't change my position one iota. Adminisrators shouldn't be 
tinkering directly with the configuration store in anything like 
normal usage, they need a toolset to do the work.

Personally, I'd like this toolset to operate through the standard API 
that everything else uses, so there's no possibility of using the 
"wrong tool". The way I'd suggest doing this would be to ensure that 
the data model exposed by the API had these two properties:

1) ACL and stacking data was exposed in the same way as other data. 
Perhaps it's a special-named key with a funky value, or another bit 
of metadata on the key.

2) Consumers of the D-BUS interface always request a "full path" to 
their configuration data, which includes the username if applicable. 
(Possibly using a shortcut of ~ somewhere.) This isn't a particularly 
onerous requirement, and would be handled by the toolkit specific 
configuration API anyway, most likely.

Then you have a configuration "master tree" which has usernames and 
scopes at the top of it, something like:

/site/  - Defaults for everyone.
/group/foo/ - Defaults for group foo. foo needn't be a UNIX group.
/user/bar/ - Configuration data for user bar.

All of them in the same "format", so that stacking works neatly.

Stacking information could be held in, say, /~/stacking, so 
/user/bar/stacking has a value of /group/foo/, and 
/group/foo/stacking has a value of /site/. The net result is that 
anyone who has permission can alter their own - or other people's - 
stacking on the fly. Most people won't have that permission, but 
administrators will.

This idea is lifted almost directly out of ACAP, just simplified 
rather heavily. This is what I meant in another thread about it being 
a good idea not to dismiss ACAP out of hand - there's a lot of good 
ideas in ACAP, whether anyone uses them or not. (ACAP is used, by the 
way, just not very heavily. If we're running a popularity contest 
though, let's all install Windows.)

Dave.