DConf Database Suggestion

[Jamie McCracken]

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.


jamie.




> 
> Dave.
> 
>