[Gpephone-devel] libsettings

[WANG Gang RD-ILAB-PEK]

Hi,


________________________________

	De : Yu Yijun [mailto:linuxstb at yahoo.com] 
	Envoyé : samedi 24 mars 2007 13:55
	À : WANG Gang RD-ILAB-PEK; Nils Faerber
	Cc : gpephone-devel at linuxtogo.org
	Objet : Re: [Gpephone-devel] libsettings
	
	

	Hi, Gang, Nils, Florian and all,
	 
	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 
	 
	libsettings, not libxsetting.
	 
	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. :( 
	 
	Since LiPS' job is to provide API standards, no one should be surprised if we provide a new set of APIs in LiPS other than reusing the GConf one or Hiker one. 
	Being standards, good quality is expected, redefining and refactoring are indispensable. But more importantly, a collaborative work is required.
	 
	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:
	
	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.
	 
	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.
	 
	Very good summarization. Just to make things clearer: settings which involve more than 1 interested parties should be stored in GConf-like setting system; private data can use ini-like storage which meets gives a better performance.
	 
	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.

	Regards
	Yu Yijun

	
________________________________

	TV dinner still cooling?
	Check out "Tonight's Picks" <http://us.rd.yahoo.com/evt=49979/*http://tv.yahoo.com/>  on Yahoo! TV.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxtogo.org/pipermail/gpephone-devel/attachments/20070326/3b73bd10/attachment.htm