An analysis about a generic desktop application configuration management system

[Maks Orlovich]

Let me add a few of my views, to those of Rich I largely agree with:

> >       * Desktop applications from all environments can work together
> >         with a few common configuration-settings. There will be no more
> >         need to duplicate these settings
>
> For me, this is a non-issue (I only care about KDE).

It would also be necessary to show that the list is non-empty, and that any 
examples are meaningful, and not better addressed by less-invasive solutions 
(say XSettings)

> >       * There's a need for an IPC system that can do signalling and that
> >         is widely accepted by most free desktop application developers
>
> Well, I'd say DCOP. :-)

Amen.

>
> >       * There's a need for a default backend database format that can
> >         store Unicode data in a tree-like structure or in a structure
> >         that emulates a tree.

You can emulate a tree in anything that's not bounded. So the requirement 
doesn't mean anything.

> >       * The the library should be easy to create bindings for in all
> >         popular programming languages.

I am looking forward to the Haskell bindings.

> >       * The programming language C (chosen because it eases the creation
> >         of interoperable libraries)
>
> I disagree, you can bind things fine with C++ and get a better
> expression of your design.

The use of C also significantly increases the migration risks and the 
maintenance downsides for us.

> For me to be the least bit interested in this idea I need to see:
>
> 1) Significant improvements for app developers vs. KConfig
>
> 2) No addition of stupid dependencies likes GLib to kdelibs
>
> 3) No loss of easy of use (eg. by using chmod vs. SQL GRANT).

I will add the following requirements, which in my view are more critical than 
anything else:
1) The risks of migration must be small. The system must be simple, 
well-tested, reliable. Destabilizing a desktop, causing porting pains to 
developers, for vaguely-defined benefits is in my view unacceptable. Also, 
migration must happen in a way that matches KDE major release schedule, 
unless it is perfectly source, binary, and runtime compatible. And frankly, 
looking at the KDE4 timeline, and your lofty list of goals that's not very 
likely (particularly the well-testedness)

2) There must be little cost of migrating applications. See (1). API changes 
must always make life easier for developers for us to be able to go to them 
and say: sorry, your app doesn't work any more, you'll have to spend 5 weeks 
porting it. 

3) If there are bugs, there must be easily diagnosable by the vast majority of 
KDE developers, without inducing vomitting. In particular, this means that 
implementations in C, in particular using glib[1], are far less usable. 
The last thing I would personally want to see is a KDE release held up because 
everyone has to go hunt for bugs in DConf, which if it were written in the 
proposed way, would be far from maintainable by KDE developers.

And to those that say that relying on external libraries decreases 
maintainership burden: it does it at the expense of quality control. See for 
example Kopete crashing due to a bug in libxslt, which is by all accounts a 
well-maintained library. I would also point out the use of libgsl in aRts, 
which made it even less maintainable by KDE people, and thus doomed it to 
death. 

[1] Note that I don't give a damn about whether you dynamically link to it, 
statically link to it, copy-paste it, sed it so every function starts with 
maksim_sucks instead of g; it's the maintainability and comprehensibility of 
the code base to a typical KDE developer that matter to me.

-Maks