DConf Database Suggestion
jamiemcc at blueyonder.co.uk
Mon Apr 11 02:58:32 EEST 2005
Dave Cridland wrote:
> 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.
Most sql servers support event notification thereby allowing the client
to listen on a tcp port for such events. A simple trigger on the
table(s) is all thats needed to deliver such notification. THere is
however no standard between servers for this communication so a
propriety solution would be needed for each type of SQL server (unless a
future libgda supports/abstracts this).
I personally dont think notification is strictly needed here cause the
kind of changes being made are more likely to be restrictions on what a
user can change or changing defaults. User config changes would
obviously not be initiated at the back end server. Centralised control
and lockdown dont necessarily need notification.
> 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.
Yes that will all help but remote admin really needs a client/server
architecture and for easy mass changes to user settings a centralised
DB. THis is meat and drink to a DBA. The decentralised route where the
DConf DBs are local to a machine is not really suited for this and for a
large enterprise it can be extremely painful to do this without a
centralised form of control.
> 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?
Yes thats right for individual users. But my understanding is there will
be multiple tables -
1) table for default settings
2) table for specifying which keys a user can update and fixed values
for ones they cant.
3) a table to hold the actual key values a user is allowed to change.
A DBA would then revoke write priveleges for a user for tables 1 and 2
and grant it for table 3.
Table 3 would also need to be prefixed/namespaced with the username so
multiple user's settings can reside in the same database on the server.
More information about the xdg