<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.7.0"> </HEAD> <BODY> 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: <UL> <LI>It will be more easy for application developers to develop desktop applications that work with configurations <LI>It will be a consistent way for application developers to develop desktop applications that work with configurations <LI>Desktop applications from all environments can work together with a few common configuration-settings. There will be no more need to duplicate these settings <LI>Network transparency for locations with large amounts of desktops (companies and organisations) <LI>A common way to manage Access Control Lists for configurations of locations with large amounts of desktops <LI>More easy to integrate with version management systems <LI>More easy to migrate from one host to another host <LI>Notification of configuration-setting changes for all applications (not only GNOME-to-GNOME applications) <LI>Can be platform independent (there's many reasons why this is useful) </UL> 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 <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">here</A>. This E-mail is not the complete document, please read the complete document if you are highly interested in this subject <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">here</A>. There's already a few existing configuration management systems: <UL> <LI>GConf <LI>KConfig <LI>OpenOffice.org's configuration <LI>Windows registry <LI>Wine emulates the Windows registry <LI>Mozilla's configuration <LI>conf and ini-files <LI>XML files <LI>There's probably others ... </UL> Such a system needs a lot requirements. You can find some of them <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">here</A>. Some of the technical considerations after taking a closer look at the requirements: <UL> <LI>There's a need for an IPC system that can do signalling and that is widely accepted by most free desktop application developers <LI>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. <LI>It would be nice if the default database would work on it's own (no need for running a "database management system"-process) <LI>The the library should be easy to create bindings for in all popular programming languages. <LI>The system should be network transparant and an IETF protocol for configuration access would be nice. <LI>The system should be integratable with source control systems or other external tools for doing version control <LI>Support for transactions in the backend is a pro </UL> That brings us to some technology choices. You can find the pro's and contra's <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">here</A>. And here is a temporary list: <UL> <LI>The programming language C (chosen because it eases the creation of interoperable libraries) <LI>The IPC system D-BUS (which will need some improvements first) <LI>SQLite as default backend (chosen above libXML because it supports transactions) <LI>Glib and GObjects (chosen because it eases the creation of interoperable libraries) <LI>GLib bindings for D-BUS <LI>ACAP (chosen because it's an IEFT standard -- better than recreating our own standard for network transparant configuration management --) </UL> We created an architectural design <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">here</A>. And we crafted a very first class diagram <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">here</A>. And finally, you can find the full document <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">here</A>. ps. Please don't draw conclusions after only reading this E-mail. Consider reading the <A HREF="http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs">full document</A> first. <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> <PRE> -- 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 <A HREF="http://www.freax.be">http://www.freax.be</A>, <A HREF="http://www.freax.eu.org">http://www.freax.eu.org</A> </PRE> </TD> </TR> </TABLE> </BODY> </HTML>