An analysis about a generic desktop application configuration management system
bastian at kde.org
Tue Apr 12 13:28:49 EEST 2005
On Tuesday 12 April 2005 00:23, Richard Moore wrote:
> > > For me to be the least bit interested in this idea I need to see:
> > >
> > > 1) Significant improvements for app developers vs. KConfig
> > Notifications and network transparency ought to provide that. I think
> > you should also add to your requirements, "No worse than KConfig."
> I agree notifications and network transparency would be nice. Certainly for
> the former, adding support to KConfig would be easier than any change of
> the underlying implementation.
To address one of your other questions, in order to add notifications and
network transparency to KConfig I am inclined to think that some sort of
central service is beneficial. For notifications it's of course possible to
add KDirWatchers in every client process to watch for changes in config files
but then you still need to reverse engineer what actually changed in the
file. If you have send your changes to a central daemon, the only thing the
daemon needs to do is to forward the changeset to applications that have
expressed an interest. The other option is to let each individual client
broadcast the changes it makes to a configuration file, but that doesn't
scale nicely because you will end up sending changes to everyone, with that
approach it will be very hard to only send it to those applications that want
it. Such a distributed approach will also be difficult wrt keep all data in
sync (See KBookmark).
Compare also with KDirNotify that we use in KIO to signal file operations as
opposed to relying on KDirWatcher. KDirNotify can provide us with semantic
information that we would otherwise need to reverse engineer from the changes
that KDirWatcher sends us.
For network transparancy I think a central approach will work better because
you have more control over the access pattern and can sequentialize update
cycles so that locking becomes less criticial. Also if your network has
relative high latency you want to cache as much as possible at the local
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050412/c3bc5f5a/attachment.pgp
More information about the xdg