An analysis about a generic desktop application configuration management system
mo85 at cornell.edu
Tue Apr 12 01:44:06 EEST 2005
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
> > * 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. :-)
> > * 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
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
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, 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
 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.
More information about the xdg