WANG Gang RD-ILAB-PEK
gang.wang at orange-ftgroup.com
Thu Mar 22 15:34:52 CET 2007
> -----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.
> >> 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!
> 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
> 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
More information about the Gpephone-devel