Re: [SyncEvolution] D-Bus API: availability of local sources (was: syncevo-dbus-server implementation)
On Wed, 2009-09-23 at 08:30 +0100, Zhu, Yongsheng wrote:
> At the moment we cannot run a sync with a temporary source
> configuration. The .other.ini node must be created somewhere. We could
> change this so that the .other.ini state is thrown away for temporary
> sources, but do we really have a use case for this?
I just think it because this is one case which might occur in 'setConfig'. From
the perspective of users, I think they don't care about whether the config is
temporary or saved. For most of users, I think saving their configs is a good idea.
This is an issue that the programs using the API need to solve or rather
avoid. In practice, none of the GUIs is going to ask for the temporary
creation of a source because they don't have that in their user
interface.
At the moment the server behavior for this case is undefined. Therefore
it is perfectly okay to treat it like you said earlier (simply ignore
the temporary source properties for unsaved sources).
> That reminds me: there are also several configuration changes
which
> should trigger a slow sync. We don't have any mechanism in place to
> force this right now. The check would have to compare the config of the
> last sync with the current config to determine whether "relevant"
> properties have changed and .other.ini is still intact. "relevant" is a
> bit hard to define, though.
Yes, should need some discussion for this. But firstly I think we could open
a bug entry to track this issue.
Please do.
--
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.