Re: [SyncEvolution] D-Bus API: availability of local sources (was: syncevo-dbus-server implementation)
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.