An analysis about a generic desktop application configuration management system
jub at sun.com
Tue Apr 12 18:26:01 EEST 2005
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
> Therefor a change notification on the configuration data distributing
> server perhaps isn't really needed. As long as a "push" mechanism is
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
> 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.
> 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
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.
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer joerg.barfurth at sun.com
OpenOffice.org Configuration http://util.openoffice.org
More information about the xdg