D-Conf

[P. Kaluza]

Hi Philip,

Philip Van Hoof wrote:

>On Fri, 2005-03-04 at 04:42 +0100, P. Kaluza wrote:
>
>>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.
>  
>
Well sure, we shouldn't make it to hard for users of the gconf api to 
switch. The same goes for the KConfig api. But if any of the others had 
a more solid codebase _for our purposes_ (which i don't quite expect), 
i'd be happy to use that as a base.

>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.
>  
>
Agreed. :-)
For example, the KConfig API has a nice accumulate changes/transactional 
commit model that fits their way of doing things (Ok-/Cancel Buttons) 
pretty good, so we should support that too.

>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.
>  
>
Exactly. However, we should try to listen to the "system config" crowd, 
because a) the end goal of one merged system (after getting rid of 
"legacy config files" in unix) does sound nice, and b) if they ever get 
of the ground anytime soon, this might hamper D-Conf's acceptance 
(because everbody will ask "why two different systems?").

>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).
>  
>
Yup. However note the work of the Elektra ppl to adopt the X server - 
that is IMHO pretty important, as the X server certainly is part of the 
desktop.

>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).
>  
>
Only for the defaults defined in the schema ? interesting thought, 
certainly better than reading the config files. With the rest I agree. :)

>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.
>  
>
Yup. But there are some good ideas in them nonetheless.

>>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.
>
sure, let's just see how it works out. nobody can promise unlimited 
development time. and work on dvfs is certainly important too (although 
not something i'd want to do).

Ciao,
  Philipp