[Gpephone-devel] libsettings

[WANG Gang RD-ILAB-PEK]

> -----Message d'origine-----
> De : Nils Faerber [mailto:nils.faerber at kernelconcepts.de] 
> Envoyé : jeudi 22 mars 2007 22:12
> À : 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 again!
> 
> Shouldn't you be @home already? It must be somewhere middle 
> of the night
> in Beijing ;) !

I am still in the office.
10:00 pm here. Pitch dark outside.

> 
> >> -----Message d'origine-----
> [...]
> >> 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 idea of the abstraction layer is that only the abstracted 
> API would
> effectively be used by application and the framework and that the
> underlying config system can be exchanged without touching the apps or
> other parts of the framework.
> But this again only makes sense if we find that we have use 
> cases where
> we would prefer something alse than GConf.

OK.
> 
> >> 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!
> 
> Excellent!
> Could he probably try to elaborate a bit on:
> - Whether or not GConf/DBus is upstream or moving there?
> - Resource usage of GConf/DBus (especially in terms of RAM)?
> 
> That would be great!
> 
> >>>>> 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
> --
>