An analysis about a generic desktop application configuration management system

[Waldo Bastian]

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

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050412/c3bc5f5a/attachment.sig>
-------------- next part --------------
_______________________________________________
xdg mailing list
xdg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg