[Gpephone-devel] libsettings

[WANG Gang RD-ILAB-PEK]

Hi, 

> -----Message d'origine-----
> De : Nils Faerber [mailto:nils.faerber at kernelconcepts.de] 
> Envoyé : jeudi 22 mars 2007 21:26
> À : WANG Gang RD-ILAB-PEK
> Cc : YU Yijun RD-ILAB-PEK; Florian Boor; gpephone-devel at linuxtogo.org
> Objet : Re: [Gpephone-devel] libsettings
> 
> WANG Gang RD-ILAB-PEK schrieb:
> > Hi,
> Hi!
> 
> [...]
> >> For the next step I would propose that someone - hehe ;) - takes a 
> >> look at *all* components in G(PE)2 and identifies
> >> a) which settings mechanisms are already in place
> >> b) what they are used for
> >> c) if and how they can be replaced by e.g. GConf.
> > 
> > I just removed the dependence on libxsettings from gpe-phonepanel, 
> > libsettings is used instead (for this moment libsettings relies on 
> > GConf).
> 
> Great!
> 
> >> Any volunteers?
> > I think I will.
> 
> Perfect, many thanks!
> 
> I just talked to Florian about it and he came up with a good 
> point for using libsettings...
> 
> We still have one possible area where we would like to have 
> an additional abstraction in settings, i.e. if we find that 
> the to be chosen config mechanism would not be suitable for 
> all intended use cases. This means in our curent discussion, 
> can we think of situations where GConf might not be desirable?
> On possible caveat of GConf could be resource usage. Is this an issue?
> If yes, when or where? Are there others? And could those be 
> avoided using an addtional abstraction which could possibly 
> allow other settings backends, like a simple text file? And 
> would that really help?
 
If we prove this area exists, will bringing in an additional abstraction layer cause inconsistency? Since then we will have 2 setting APIs: Gconf and the 'additional abstraction layer'. 

> 
> The resource usage of GConf is indeed an issue. But we should 
> research a bit on that and find out how big the impact really 
> is. Nokia resolved that to a certain extend by using GConf on 
> DBus. This is nice, not exactly the slimmest method but 
> already very good. But is GConf-DBus upstream? Is it maintained?

It needs digging a little bit deeper before we can draw a rational conclusion.
One thing needs mentioning is that Yijun had ported Gconf (depending on DBUS) to philips 968, it's a good starting point for us to try it out!

> 
> >>> BR
> >>> Gang
> Cheers
>   nils faerber
> 
> -- 
> kernel concepts GbR        Tel: +49-271-771091-12
> Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
> D-57072 Siegen             Mob: +49-176-21024535
> --
>