DConf configuration system

Patrick Patterson ppatters at nit.ca
Thu Apr 7 19:04:29 EEST 2005


On April 7, 2005 09:56 am, Joerg Barfurth wrote:
> Patrick Patterson wrote:
> > On Wednesday 06 April 2005 15:00, Jamie McCracken wrote:
> >>If Uniconf is really suitable as a desktop config system then why are
> >>some of us looking into creating an alternative like DConf?
> >
> > And your final question is what we've been asking ourselves for quite a
> > while. :)
>
> Whenever I looked for information about what Uniconf *actually* does
> *today* and how it does it, all I found was a bunch of not very
> organized and apparently (largely) outdated wiki pages.
>
Sorry - as Avery mentioned - we have been working diligently on it internally, 
and I guess that we've been negligent about posting updated information to 
the Wiki. However, the API Docs should be up to date, since that comes out of 
the CVS tree every night :)

> As I was not willing to read a big pile of source code (throw in your
> Stream package for good measure) I soon quit. Additionally it looked
> like UniConf's primary goal was to provide infrastructure to wildly mix
> and stack various existing bits and pieces instead of aiming for the one
> successor to most of these pieces that can be used by all desktops (and
> desktop-neutral apps!).
>

Well, we knew that getting everything else to suddenly drop what they'd been 
doing forever and switch to UniConf wasn't going to happen, so when we were 
designing it, we built it so that you could start off simply using it as a 
bridge between the different configuration systems, and then slowly migrate 
to a native utilization of UniConf. 

> I think all this stacking and adapting can be a useful approach for
> providing a unified administration interface for legacy configuration
> data - particularly for system services. Here rewriting things to not
> use their special configuration systems directly any more is huge work.
>
> OTOH the 'front-end' part of this (i.e. adapters for existing client
> APIs to talk to a DBUS API) could be useful, but here there wasn't
> really any documentation at all - or I haven't found it.
>

As Avery mentioned - it's in the Unity CVS project, but we didn't do any 
documentation for it. We'll have to get to that REAL SOON NOW, I guess :)

> To be a candidate for an XDG standard, clear documentation with detailed
> semantics is surely required.
>
Fair enough... 

> Ciao, Joerg

-- 
Patrick Patterson
Technical Ambassador
Net Integration Technologies R&D



More information about the xdg mailing list