D-Conf

[P. Kaluza]

Hi Avery, Sean, all,

>A note here, since we seem to be coming at two different angles.  You
>are coming from the perspective that we will without doubt use an
>existing system, and that the trick is determining which system to use.
>I'm coming from the angle that we just started talking about D-Conf,
>that actual code (already existing or not) is rather irrelevant, and
>that the point of the current discussion is to decide the requisite
>features of D-Conf.
>  
>
Just wanted to say i completely agree with Sean on this. I find it much 
more sensible to discuss an apppropriate and solid API, then start 
implementing it, reusing code if possible, but starting from scratch if not.
  While I did ask for status (and direction) reports from existing 
projects, I thought it went without saying that any project truely 
aiming at "becoming D-Conf" would be willing to change APIs and 
direction to do so (when that direction is finally agreed upon by xdg@).
  At this point in time, we're just not ready to choose yet - 
unfortunately. We don't even have the basic requirements. Making 
something a requirement just because it's a feature somewhere does not 
sound sensible.


That said, Sean, I would like to see an LDAP backend sometime. I've been 
using LDAP for quite some time now, and think it provides a powerful 
data model, if used correctly. However, the gconf-data-in-LDAP thing 
never happened (at least for me). But when the Hula project was 
opensourced recently, (though i haven't actually _used_ it yet) I was 
amazed at how integrated a system could appear when all he user 
configuration data is managed in an directory. This is something i'd 
like to have on my and my users' desktops, too, in the long term.
  So I would indeed vote for pluggable backends, and I hope I also 
argued for it. :-)

I'm also pretty convinced we'll need a daemon, but i'll argue for that 
later.

Ciao,
  Philipp