[Gpephone-devel] libsettings

[Florian Boor]

Hi,

Yu Yijun schrieb:
> Regarding the setting service, the following is my answers and ideas: 1. I
> agree now that the current libxsetting library is on the right way for
> setting service. A set of generic APIs like this will not only simplify
> application developers' job, but also be much likely compatable with the
> coming corresponding LiPS spec. Setting service will be one work item of LiPS
> and I personally believe that neither APIs of GConf not those of Hiker 
> setting service will be accepted as LiPS APIs, instead, a set of generic APIs
> like this should be defined. However, the risk is that we can't guarantee
> that the current APIs defined by Gang will be accepted by LiPS too.
> Therefore, on the one hand, Gang should well prepare the APIs and documents
> and we can propose to LiPS as setting service spec candidate; on the other
> hand, we should feel no suprise that if some day we need to re- define the
> APIs and modify relevant code. :(

It might be a good idea to take a more close look at the design criteria of
existing specifications and implementations for settings storage. I suppose this
might teach us quite a lot about how to design the API to be flexible enough to
be useful as a generic LiPS specification and still easy to use to be accepted
by all application developers.
I checked the current implementation and I do not think that it is too bad. Of
course we could develop a more object oriented or more complex API but the
current one is quite likely to fit the basic needs.
One major thing we should think about is a mechanism to feed the settings
database with default values. It might be nice if not every application needs to
implement this in its code.

> 2.I am not sure I fully understood what you mean about the additional 
> abstraction of setting. But to be frank, I really feel confused that what
> parameters should be stored where. it seems that it is quite definitive to me
> that the following types of parameters should be stored in Gconf like
> services:

In this context I guess libsettings would be the additional abstraction. An
alternative solution might be use Gconf directly.

> 1) The parameters that are quite likely to be modifiedy later by operators
> remotely. These parameters should be standardized as Device Management
> Objects and operators are able to manipulate them remotely. 2) The parameters
> that are concerned by more than one applications and are likely to be 
> modified later by some applications. When one application modifies the 
> parameter, notification mechanism of Gconf should be used to notify other 
> applications the change, and other application may react accordingly.
> Parameters like these include device theme, languange setting, etc. 3) The
> paths of the applications' and system's resource locations (including
> picture, sound, config files, etc). Applications use predefined keys to get
> these paths. Parameters like these are got by environment variables
> originally.

Right, I agree...

> For other parameters, I am not sure whether they should be stored in the 
> Gconf, however, sometimes it seems that an .ini file is much easier to use if
> there are quite a few parameters that: 1) are only accessed (r/w) by a single
> application; or 2) are system wide parameters predefined before the device is
>  distributed and never changed later (ro) Therefore, in my personal opinion,
> I think both Gconf like service and GKeyFile like service should be provided
> and there is no need to provide a single set of APIS for both of the 
> services.

That's true... for some settings you can use the one or the other method.
Especially for settings relevant to one application only or settings that are
usually read only it is nice to use GKeyFile for. Of course there are some
settings for which both methods would fit but generally it should be easy to
decide which mechanism to use.

> 3.Regarding GConf-DBus, as fas as I know, the Nokia version of GConf-DBus
> will not be accepted upstream, instead, a new GConf-On-DBus will be
> developped from scratch based on the latest DBus APIs by the current GConf
> developers. For detailed info, pls refer to 
> http://www.gnome.org/projects/gconf/plans.html and 
> http://mail.gnome.org/archives/gconf-list/2005-March/msg00000.html . Anyway,
> I don't think it can stop us using GConf-DBus for the moment since APIs will
> be always the same. we can smoothly move to the new version of GConf-On-DBus
> later. Currently I don't have detailed data on the performance of the 
> GConf-DBus, but I think it should be quite good since the whole demo system
> is running on a 32M RAM device.

I just hope someone is working on implementing what they planned - it sounds
quite promising :)

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-14
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor at kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76