-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

just a summary email aiming for brevity and clarity, with a few additional 
notes at the end:

On Wednesday 13 August 2003 01:16, David Findlay wrote:
> - No configuration history - can't see when and who changed stuff

for desktops, almost irrelevant. it's either the user or an admin.

> - No way to roleback changes

this would be nice, and is something that is addressable within the current 
framework.

> - Could work in with Kiosk mode, allowing administrators to control some
> settings, while leaving others to users

KConfig already allows locking down of files, groups and even individual 
settings. this is a big part of how Kiosk manages to work at all.

> - Configurations could be stored seperately from home directories for easy
> management

already possible with $KDEHOME and/or network filesystems.

> - When i want to change a setting manually i have to find the text file. In
> an ideal system you could open a registry browser, follow the tree to a
> property and modify it.

Zack's working on such a thing, Waldo and Zack have been working on metainfo 
(commens, allowable values, etc).

none of the above really says "we need a new config system". here are my three 
big wishlist items, however, that may require at least some additional 
infrastructure:

 o notifications of changes. i worked around this in the Kicker control panel 
and my GOD was it annoying. basically i put a dirwatch on the config files 
and read in the whole thing and reconfigure everything when it changes. this 
is pretty crazy =) for apps that need such notifications, it would be nice if 
a KConfig object could be instatiated for the life of the application that 
would then automatically update itself when the settings data changed and 
even emit signals to that effect. i talked w/Zack on IRC about this, and it 
looks like (hopefully) there will be some discussion at n7y regarding it...

 o effective and useful network storage of data, either in LDAP or in an 
RDBMs. either way, network traffic needs to be kept down, which means both 
batch retrieval of data and local caches. this may also imply some means on 
the server end to notify when caches are invalid, settings change, etc.

 o a system _within_ KDE to propagate settings across a network to many 
systems. whether this is just a front end to CVS/rsync or is an addition to 
kconfedit that allows it to be run in daemon mode and accept file transfer or 
is a DCOP-over-the-network extension or... hardly matters to me. but having 
to set up rsync/CVS servers and config the clients appropriately "by hand" in 
a larger installation (which i've done) isn't something i'm particularly 
proud to market =) it works, it just doesn't come in a very sexy package

- -- 
Aaron J. Seigo, Geeko
Urbanlizard.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/OmEu1rcusafx20MRAjckAJkBxPbcnyeE5TQm3klCUNeduBnOyACaAjhQ
9pv8t99Hp52OZm9Aan3fFCQ=
=J1dj
-----END PGP SIGNATURE-----
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<