An analysis about a generic desktop application configuration management system

[Richard Moore]

On Thu, Apr 07, 2005 at 08:32:41PM +0200, Philip Van Hoof wrote:
> 
>       * It will be more easy for application developers to develop
>         desktop applications that work with configurations 

Not so, as long as they use the framework of the desktop, this already
easy.

>       * It will be a consistent way for application developers to
>         develop desktop applications that work with configurations 

Again, most desktops provide tihs already.

>       * 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).

>       * Network transparency for locations with large amounts of
>         desktops (companies and organisations) 

This could be a win from a new system, though it would need to prove
itself to have significant benefits over NFS exports to be real.

>       * A common way to manage Access Control Lists for configurations
>         of locations with large amounts of desktops 

I'm not sure what this means.

>       * More easy to integrate with version management systems 

This is already very easy with KConfig.

>       * More easy to migrate from one host to another host 

Again, not really a problem I've every encountered.

>       * Notification of configuration-setting changes for all
>         applications (not only GNOME-to-GNOME applications) 

Only relevent if the system is already shared between desktops, but
ok.

>       * Can be platform independent (there's many reasons why this is
>         useful)

KConfig already is, what do you mean? I'm sure Gconf is too.

[snip]
> 
>       * 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. 
>       * It would be nice if the default database would work on it's own
>         (no need for running a "database management system"-process) 
>       * The the library should be easy to create bindings for in all
>         popular programming languages. 
>       * The system should be network transparant and an IETF protocol
>         for configuration access would be nice. 

Why? I think latency would kill network transparancy here, and I don't
see why the IETF matter either.

>       * The system should be integratable with source control systems or
>         other external tools for doing version control 
>       * Support for transactions in the backend is a pro

[snip]

>       * 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 IPC system D-BUS (which will need some improvements first)

Again, I prefer DCOP.

>       * SQLite as default backend (chosen above libXML because it
>         supports transactions)

I am far from convinced XML

>       * Glib and GObjects (chosen because it eases the creation of
>         interoperable libraries)

Over my dead body.

>       * GLib bindings for D-BUS

See above.

>       * ACAP (chosen because it's an IEFT standard -- better than
>         recreating our own standard for network transparant
>         configuration management --)

Don't know this, I'll look into it.

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

The above are a minimum, I don't see it so far. Note, this doesn't
mean that I can't be persuaded in the future.

Cheers

Rich.