future of gconf

["Sergey V. Spiridonov" <sena hurd homeunix org>]

Hi ,
here are some ideas concerning gconf project and some experience, which 
I hope will be useful.

1. Introduction.

One year ago a read gconf documentation and like its idea very much. 
Unfortunately the company where I worked was not able to use gconf 
because of the licensing issues. But I use  gconf ideas and find out 
that they work very nice. I think it is time to give back some of the 
experience I got from implementing some of the gconf ideas. Hope they 
will be useful for the gconf developers. Hope I will find a time to 
contribute also some code to the gconf. Please note: I am not gconf or 
gnome developer, but I want to become one. Everything I know about gconf 
is documentation from gnome.org.

To help understanding what I will talking about, I have to describe the 
area where I tried to implement some of the gconf features. We have a 
bunch of engines which perform some useful tasks and another bunch of 
the main applications which perform engine initialization, control and 
user interfacing. Both engines and main applications have configuration 
parameters. Engines are runnable on various platforms (including for 
example DSP). Sometimes main application is a daemon without user 
interface (UI). That's why there there was a need to have full-featured 
setup tool (a-lya gconf-edit) to configure engines without UI.


2. Extended constraints.

What I like in gconf most of all is standartization. Strandart API, 
standart notification mechanism, standart backend(s). I hope, one day in 
the  far future we will forget about the /etc nightmare . There is one 
step which is still not done: standart server-side language. It is 
needed to have extended constraints for configuration parameters. Simple 
example: we have parameter A, B, C and there is a need to be sure that A 
is always less then B+C. In this example the constraint "A<B+C", should 
be checked each and every time when A, B, C parameters are updated.

Why server-side?  Of course, this check can be done in application, but 
it is too late in case we use gconf-edit. The check should be done 
*before* the "wrong" value will be stored in database. Most of the 
modern databases have constraints and triggers. They are used for values 
validating on the server side.

Which language should be used for this standart? I don't care too much. 
I think guile is O.K. for such a task. I like guile and it is default 
GNU extension language.

Server-side language feature  depends also on the transaction 
functionality. I have no idea, on which stage it is in gconf. If we will 
check an example above, there is a need to have something like "start 
transaction"-"A=1, B=2,C=3"-"commit work" scheme.

In our project we implemented a kind of such a language.


3. User interface. (UI).

Another problem we faced with is not solved in gconf. It is UI in the 
standart setup tool. We moved parameters integrity checking into the 
server-side. The next step was to implement full-featured "configurating 
tool". What is "full-featured"? I mean all this "stupid" check-boxes, 
sliders, frames, tabs, dialogs in the "usual" application configuration 
dialog.... AFAIK, gconf-edit uses regedit-like tree widget and standart 
dialogs which are binded to the parameter type.

What can be done here? Well, here is how we solved it: we describe all 
this dialogs, tabs, checkboxes in XML and store this description 
together with configuration database. And it works!

Let's imagine,  the same is done for gconf. Applications install XML 
description of configuration dialogs together with parameters. From this 
point gconf-edit can look like the same as if you will open application 
configurating dialog. Application itself can use this UI descriptions, 
stored in the gconf database to buiild UI configuration dialogs 
"automagically". Together with server-side language with triggers, we 
will have full-featured "configurating tool" (gconf-edit), which will 
provide UI, which is designed by the original application developer.


It's not everything I want to say about gconf, but it is enough for one 
mail. I would like to do something in this area and hopefully I will get 
a timeframe to work on this.
Thanks for taking time to read my mail, I know my English can be 
improved a lot
--
Best regards, Sergey Spiridonov