An analysis about a generic desktop application configuration management system
Philip Van Hoof
spamfrommailing at freax.org
Thu Apr 7 21:32:41 EEST 2005
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
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:
* 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
* 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
* Glib and GObjects (chosen because it eases the creation of
* 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg