DConf Database Suggestion

[Dave Cridland]

On Sat Apr  9 11:56:22 2005, Jamie McCracken wrote:
> I was wondering if it might be better to use libgda as an API to 
> the backend rather than using the Sqlite API directly.
> 
> 
Probably, but I personally think it's way too early to be talking 
about implementation details. Moreover:

> One of the advantages of using a client/server RDBMS will be easy 
> remote control and lockdown of settings. A DBA which most 
> enterprises will have can easily use the SQL grant/revoke to 
> prevent write access to tables that dconf utilises (something which 
> might prove difficult to do with Sqlite as it has no user 
> authentication). Indeed remote administration will also be most 
> effective this way.

Since SQL doesn't have notifications, tweaking the configuration via 
SQL will likely turn out to be a bad idea. You'll lose any 
possibility of if-not-modified-since style functionality working, in 
this case. Havoc will most likely say that this doesn't matter - I 
think it does. Any administrator going behind the configuration 
system's back deserves the problems it will cause.

FWIW, I'm pretty certain that, given the relative ease of handling 
D-BUS interfaces from Python et al, a huge bunch of command-line 
utilities for helping administrators manage the system will spring 
up, and make hitting the config system's storage an ugly waste of 
time anyway.

For the specific task of lockdowns, etc, I find it unlikely that 
SQL's GRANT functionality will be up to the task of handling the 
granularity of ACL that a configuration system requires. Wouldn't 
this only be able to, in effect, control SELECT, UPDATE and INSERT 
across entire tables?

Dave.