DConf Database Suggestion

[Dave Cridland]

On Mon Apr 11 00:58:32 2005, Jamie McCracken wrote:
> 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.
> 
> 
Oh, I think they do.


>> 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.
> 
> 
Yes, but given multiple implementations, etc, I suspect the tools 
will exist anyway, and be much more convenient and considerably safer 
than letting a DBA loose on the system.



>> 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.

I personally think that here, you're getting very bogged down in the 
implementation details of a system which doesn't exist.

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.

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.

Dave.