[Desktop_architects] Deskop configuration management

[Aaron J. Seigo]

hi philip..

before i comment on the email and spec itself (which i do below), we need to 
ensure that we don't go at it back-asswards (yet again). instead of trying to 
posit a standard at the umbrella level and then getting everyone to implement 
it (a pathway to and from failure), standard possibilities need to be shopped 
to the major projects for adoption. as the projects adopt it, then it becomes 
a standard (because it is). this way we have confidence not only in adoption 
but in the fact that it works. this reflects how we actually work, and it 
seems that there is a strong corelation between success and failure of a spec 
and which route is taken.

therefore i'm reading this email as a kde guy looking at this spec as a 
proposal within the kde community to replace what we use now. i will reply as 
such as well. ok.. (important) preamble out of the way:


desktop configuration storage formats are boring and not seen by the app 
developers, so probably make for an interesting place to work on 
standardization. given that we will be replacing systems that exist, we ought 
to ensure that it works better than what we have, otherwise there's little 
purpose to it.

i don't see good reasons presented to do this given the spec provided. it's 
just another configuration system. it says little about the whole purpose 
behind unification: common policy management. the little it does say is that 
"now there'll be just one format!" which is hardly a win of the size that 
would make most desktop developers say, "we must obviously adopt this asap!"

have you, or anyone else, looked at uniconfig, btw?

On Tuesday 27 December 2005 08:39, Philip Van Hoof wrote:
> https://svn.cronos.be/svn/deconf/deconf-spec/trunk/src/deconf-spec.xhtml

i have several questions and many concerns about this particular proposal. 
here are some of them...

questions:

 - speed penalties associated with using XML at runtime? configuration is 
pretty key to application startup times and a fearsome number of config keys 
can be read in quick order. in kde we've seen both sides of this coin: 
optimizing KConfig for speed and seeing how XMLGUI makes things slower =)

 - performance of DBUS. what's the performance and reliability of DBUS these 
days? it will need to be rock solid and adequately fast to be accepted as the 
carrier of something like this

concerns:

 - portability. i see a reliance on environment variables and D-BUS. we ought 
to ensure this runs on more than just UNIX.

 - XDG_DATA_DIRS. this has already caused problems for us with the menu spec 
in that it can't be changed within a session, can't be changed by installing 
a new desktop (think of multiple desktops on the same system) and if often 
just plain set incorrectly (if at all) by packagers. honestly, using 
XDG_DATA_DIRS was a huge mistake. i have the numerous (invalid) bug reports 
to back that statement up. let's not replicate that mistake to other specs.

 - dynamic values. in kde we have the ability to provide for dynamic values to 
a key; essentially commands that are run to decide what the value should be. 
i don't see allowance for that in the spec.

 - multiple config dirs. in kde we have the ability to define sets of 
configuration directories, allowing for overlayed and cascading 
configurations. i don't see allowance for that in the spec. i do see the 
concept of "subsequent namespace components" but that seems to be happening a 
rather uncomfortable location in the hierarchy given the purpose of 
unification (providing management and group config).

 - ease of use. the spec requires the definition of an xml .schema file, or is 
that optional? if it isn't, that's just one more bar we're putting in the way 
of the app developer. they ought to be able to simply read and write 
requests.

 - justification for design. the design of "central service + XML schemas + 
DBUS IPC" is positted but no rational is given for either the generic design 
nor the exact mechanism. i'm very wary of such "designing in a vacuum" 
approaches, and i won't be the only one like that who reads this.

 - migration. for our existing installations who have non-trivial investments 
in configuration and lock down configuration (something kde is very good at 
already), we'll need migration paths. has any work been done to appraise 
costs and methods for migration?

 - migration mark two. many kde applications use spaces or slashes in their 
key names. this means lots of changes in code and lots of value migrations. 
ergo items like "All characters with exception of the slash and the space are 
allowed for preferences." are not fun.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/desktop_architects/attachments/20051227/53933b1d/attachment-0001.pgp