An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

Hi there,

Me, Kristof Vansant and Frédéric Descamps created a small (and
unfinished) analysis for a generic desktop application configuration
management system which we'll call D-Conf (it's just a temporary name,
perhaps the final name. We'll see).

I kindly invite people who are interested and who perhaps have a
specific knowledge in a topic that might be important for this project,
to append and/or correct the information we are collecting during the
analysis of it. I kindly invite people to join. It's the main reason why
it has been created in a wiki-container. It's possible that this
document will move to a more appropriate location. Thats why the
wiki-title of the page mentions the fact that this is a temporary
location. We'd like to have a more or less stable and clean document
before officially publicising something.

There's a few reasons why such a generic system is a good idea:

      * It will be more easy for application developers to develop
        desktop applications that work with configurations 
      * It will be a consistent way for application developers to
        develop desktop applications that work with configurations 
      * Desktop applications from all environments can work together
        with a few common configuration-settings. There will be no more
        need to duplicate these settings 
      * Network transparency for locations with large amounts of
        desktops (companies and organisations) 
      * A common way to manage Access Control Lists for configurations
        of locations with large amounts of desktops 
      * More easy to integrate with version management systems 
      * More easy to migrate from one host to another host 
      * Notification of configuration-setting changes for all
        applications (not only GNOME-to-GNOME applications) 
      * Can be platform independent (there's many reasons why this is
        useful)


So to complement the first dialog of this E-mail: if you disagree with
the list of reasons you can actually go ahead and correct it. Same for
all the following pieces of this E-mail. So don't just argue and flame
about it, do something about the problems and errors. Go fix them here.
This E-mail is not the complete document, please read the complete
document if you are highly interested in this subject here.

There's already a few existing configuration management systems:

      * GConf
      * KConfig
      * OpenOffice.org's configuration
      * Windows registry
      * Wine emulates the Windows registry
      * Mozilla's configuration
      * conf and ini-files
      * XML files
      * There's probably others ...


Such a system needs a lot requirements. You can find some of them here.

Some of the technical considerations after taking a closer look at the
requirements:

      * There's a need for an IPC system that can do signalling and that
        is widely accepted by most free desktop application developers 
      * 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. 
      * 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


That brings us to some technology choices. You can find the pro's and
contra's here. And here is a temporary list:

      * The programming language C (chosen because it eases the creation
        of interoperable libraries)
      * The IPC system D-BUS (which will need some improvements first)
      * SQLite as default backend (chosen above libXML because it
        supports transactions)
      * Glib and GObjects (chosen because it eases the creation of
        interoperable libraries)
      * GLib bindings for D-BUS
      * ACAP (chosen because it's an IEFT standard -- better than
        recreating our own standard for network transparant
        configuration management --)


We created an architectural design here. And we crafted a very first
class diagram here.

And finally, you can find the full document here. 

ps. Please don't draw conclusions after only reading this E-mail.
Consider reading the full document first.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20050407/fb4f270d/attachment.htm