[Gpephone-devel] libsettings

[Yu Yijun]

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
  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. :(
   
  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.
   
  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" on Yahoo! TV.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxtogo.org/pipermail/gpephone-devel/attachments/20070323/9bac761e/attachment.htm