D-Conf (was: Post or during the Common VFS (D-VFS) ages ..)

[Philip Van Hoof]

On Fri, 2005-03-04 at 04:42 +0100, P. Kaluza wrote:

> This topic has been nagging me for quite some time now, more from the POV of
>   http://www.freedesktop.org/Standards/config-spec
> (which you probably were also aware of, judging from your mail). In 
> december i got pretty fed up with it and started fleshing out some 
> interface ideas, but RL cought up with me again before i had anything 
> good enough to post (however i'll look where i put that stuff).

The wiki-page is a good start, of course. 

> I researched in the list archives and on different project-pages, and 
> one thing i perceived as (historically) problematic is that there are 
> really too many projects aiming at becoming "the one true FLOSS 
> configuration system". As I'm not really eager to tread on anyone's 
> toes, before getting started on the technical details, let's get the 
> politics out of the way and have a little informal survey:
>   "Who is still aiming at becoming XDG's recommended config system ?"

> Specifically:
> - Avery, what is the status of UniConf ? what is your current main focus ?
> - Havoc, have your nice "GConf NG" ideas ever been cast into code by the 
> gconf team ?
> - What about the Elektra team ?


As far as I know. At this moment is GConf the only system of these three
that has a wide userbase. My opinion is that this fact can play an
important role when the migrating-part starts.

. . .

Edit after I typed all this: Beware that I 'am' a GNOME/Gtk+ application
developer. Therefor it's possible that I 'will' indeed prefer using
technologies I already know. Just as Sean often replies in the subject
DVFS: "I'm open to being proven wrong".

Actually.. IMHO we should all be open to being proven wrong.

. . .

 
We don't need a system that will magically convert files from /etc/ and
all dotfiles in your $HOME into a unified database with triggers. Well
perhaps the UNIX-world does need such a system but it's not within the
scope of what the desktop-world needs. Perhaps later in time, both
systems will work together or merge their features. But for me, at this
moment, desktop-application configuration and system configuration are
two different things.

What we need is a registry-system for DESKTOP applications. It's only
for the desktop applications. I don't think configuring apache with it
is interesting. I don't believe system administrators would like it that
way. And I'm certain the apache-team won't ever convert apache to use
that system (nor any other UNIX system-service).

This desktop configuration system should have events and triggers for
when values change. It shouldn't encourage binary data. It should
encourage documenting keys. It should work network-transparant at
protocol-level. This way a configuration daemon can be running on a
dedicated host and clients can then work with it. Therefor it should
have fallback mechanisms for in case the daemon can't be reached (to use
a default scheme distributed with the applications).

The future plans of GConf are all addressing these needs that are,
indeed, very specifically targeted at the needs desktop applications
have.

Perhaps there might be a need to push new configuration to distributed
configuration daemons. For example when your company has multiple
configurations. Suddenly you, as the administrator, want to push a
specific configuration key/value on all those different
configuration-sets without altering their individual specific configs.

I don't know what undo/redo capabilities GConf has, but I've read it has
planned such features. I don't know how atomic/transactional GConf is,
but I've read it has planned such features.

GConf can store it's configuration-data using different backends. XML is
it's default and I'm not sure whether or not it is a real requirement to
have multiple backends. I'd say its a "nice to have"-feature. As long as
the data can be properly backed up and restored (XML can).

But GConf really needs to get rid of it's current dependencies (mainly
ORBit-2 and glib). Replacing ORBit-2 with DBUS (which is also planned)
might be a good start. And removing the "G" from the name will stop
making the kids think this is a GNOME-only technology. Thats why I
propose the name D-Conf :-) or XD-Conf. For Cross Desktop Configuration
system.

> Please note that i am NOT interested in any "and you can stack system X 
> ontop of Y"-type arguments - these will help in evaluating neither X nor Y.

Indeed. Most of the features a lot authors tried as arguments for trying
to get their system accepted as "the standard" aren't worth it or aren't
going to be actually used for desktop applications. Desktop applications
don't need all that much. They certainly don't need to query files like
apaches /etc/[apache|httpd]/httpd.conf.


> After getting this overview about the different visions and project 
> states together, we can then (if necessary) discuss once more everyone's 
> pet flame topics, like
> - license choices
> - language choices
> - strengths and weaknesses of existing architectures
> - and how to convince more KDE developers that a daemon is cool here 
> (sorry Waldo, CNR :-))
> But let's keep in mind to go forward, not turn in circles.

Yes, thats very important. I've given up on reading the previous threads
about this subject because lets face it: they aren't worth reading. They
are really scaring away people who actually want to do something about
this.

> >Therefor it perhaps wouldn't be wise if I was
> >the only person to draw a design for it.
>  

> So Philip, to answer your implicit question, i'd be glad to work with 
> you on this. :-)

I'd be glad to help any serious efforts on this. Just as I'd be glad to
be the "extra brains" for projects like DVFS. Which of these projects
will get most of my attention and development time will of course highly
depend on many factors. My plans are, however, to help at least one such
project with both development and implementation.

My personal efforts wont be all that important. What will be much more
important is the overall acceptance of the people who are the current
developers of the UNIX (free)desktop.

Somebody already said this on this mailinglist, I forgot who: We agreed
to use English for these discussion. It's not a technically perfect
language. Esperanto probably is a perfect language in that aspect. But
English works. Esperanto probably wouldn't. It wouldn't work out if some
of the people here start speaking French, German and Spanish. I can
understand and read French but I can't understand nor read German or
Spanish. We all agreed to try it with English. I'm not a native English
speaker so no, it's not a perfect language. But it works. Lets get the
freedesktop working. And lets start with agreeing on such standards.



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