An analysis about a generic desktop application configuration management system

[Joerg Barfurth]

Philip Van Hoof wrote:

> I'd like to note that in the current idea, the backend of the deamon
> will cache as much data as possible on the local stores of the many
> desktops (thats all to-the-user-relevant configuration data).
> 

Yes. How to cache, what to cache and when to cache should be up to the 
backend.

> Therefor a change notification on the configuration data distributing
> server perhaps isn't really needed. As long as a "push" mechanism is
> provided.
> 

True. The backend needs some way to learn that data has changed on the 
server. Different backends working with different kinds of servers can 
do this in different ways and driven by different policies. In some 
cases 'push' mechanisms can be made to work, in others 'pull' mechanisms 
do (scheduled pulls, session events, polling).

> One that can be instructed to overwrite the caches of the many local
> stores of the many desktops who authorized that alien service to do that
> at a certain moment in time (when the administrator wants it to happen).
> 

This is the important part. The backend (or whoever detects a change) 
needs a way to notify the config system of this, so it can invalidate 
its caches.

> A change notification of settings on the enterprise LDAP server would
> only be a requirement if desktop client x wants to be notified about
> configuration changes done by desktop client y.
> 

No. I fact a LDAP backend should almost certainly be read-only for 
ordibary configuration clients. Changes on the LDAP server would be done 
by administrators and they need not be done through the same framework 
as normal preference updates. But there needs to be a way for clients x 
and y to learn about changes on the LDAP server that apply to one or 
both of them. But probably that needn't be instantaneous.

> In fact I haven't seen that as a requirement from somebody. What people
> are requiring is a way to distribute new configuration to many desktops
> and to split "the many desktops" into groups. 

Right.

> And to do some sort of
> version management with the configuration data. Preferable with existing
> source control management systems.
> 

Some support for revisioning is useful. But this would probably be tied 
to each backend. I am not sure support for classical source control 
systems is really a that fundamental requirement. Where backends don't 
support that out of the box you can do that with text im-/export.

> I know that the usage of local caches (and trusting that local cache)
> will make it impossible to make it impossible to overrule a certain
> configuration setting. 

It depends on the content of the local cache and the way it is managed. 
But yes, you can't probably prevent tinkering with or supressing such 
settings. But most ordinary desktop users won't be able to do that. 
Typically advanced system experts that can circumvent this kind of thing 
aren't the target of desktop lockdown.

> I don't think "security" on that level is an
> important requirement. The read-only keys are more likely to be used to
> protect the users from setting foolish settings. Rather than to make
> sure they can't set them or they can't overrule them.
> 

The point isn't security. It is control. If you can prevent a user from 
overruling a certain setting, that should include that you can do this 
after the fact - i.e. when the user already has a 'foolish' setting or a 
setting that violates new company policy in their preferences.

> I can imagine an administrator changing the company proxy-settings for a
> certain group of people. The the configuration data distributing server
> will, in such a case, signal the many D-Conf daemons about this change.
> And they will be responsible to get the new information from the
> distributor, and overwrite their cache with it. No real need for change
> notifications.
> 

But what is 'the server will .. signal the many D-Conf daemons about 
this change' if not change notification. 'The server will notify clients 
of changes, but there is no need for change notifications' is 
contradictory. Note that change notifications need not and generally 
should not transport the changed content. In general, particularly for a 
caching implementation, a change notification should invalidate the 
cache and possibly trigger a reload.

> However .. these are already technical details. What I want to clarify
> is that therefor a standard LDAP is suitable.
> 

Yes it is. If you want to do automatic change propagation with LDAP, 
have the client check or poll for changes according to its own schedule. 
Of course you can support one of the existing extensions if available.

Ciao, Joerg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at sun.com
OpenOffice.org Configuration          http://util.openoffice.org