DConf Database Suggestion
dave at cridland.net
Mon Apr 11 02:26:35 EEST 2005
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
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?
More information about the xdg