Also have a concern about setConfig: I think we should allow setting a new source temporary and don't flush it to files and make it in use when doing a sync. We set the new source and its configs in the filter. In this case, when doing sync and checking active sources, current implementation returns sync sources in the 'sources' directory so the temporary new sources won't be in use.
My proposal is: Set all properties belonging to that new source in the configuration source filters. When getting sync sources, We combine sources from 'sources' directory and sources in the source filters. Cheers, Yongsheng -----Original Message----- From: Ohly, Patrick Sent: Friday, September 18, 2009 4:19 PM To: Zhu, Yongsheng Cc: Jussi Kukkonen; SyncEvolution Subject: RE: D-Bus API: availability of local sources (was: syncevo-dbus-server implementation) On Fri, 2009-09-18 at 06:06 +0100, Zhu, Yongsheng wrote: > Another issue from dbus interface is: > | "Cleared" in this context means that all existing > | properties are removed before setting those passed as > | argument. > > The properties which are removed are commented and not set with empty string? They are wiped out completely. Basically "Cleared" means "remove everything from "config.ini" and then fill the file with the properties which were sent by the D-Bus client. > | Configuration entries (the user-visible part as > | well as the related meta information, plus the containing > | directory if it is empty) which are not referenced by a > | key in the configuration are removed. > > If any settings for 'addressbook', then 'addressbook' directory will be > removed? If there are no settings for 'addressbook', then all SyncEvolution files in the 'addressbook' directory can be removed, including the directory if it is empty afterwards. See the implementation of the --remove options for an example how this is currently done. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
