> 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.
> 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. Cheers, Yongsheng -----Original Message----- From: Ohly, Patrick Sent: Wednesday, September 23, 2009 3:09 PM To: Zhu, Yongsheng Cc: Jussi Kukkonen; SyncEvolution Subject: RE: D-Bus API: availability of local sources (was: syncevo-dbus-server implementation) On Wed, 2009-09-23 at 07:43 +0100, Zhu, Yongsheng wrote: > 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. 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? Change tracking would be considerably messed up, in particular because the Synthesis engine doesn't know that the source requires a slow sync. 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. -- 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
