https://bugs.freedesktop.org/show_bug.cgi?id=63471 Priority: medium Bug ID: 63471 CC: syncevolution-issues(a)syncevolution.org Assignee: syncevolution-issues(a)syncevolution.org Blocks: 56141 Summary: PIM: more information about sync Severity: normal Classification: Unclassified OS: All Reporter: patrick.ohly(a)gmx.de Hardware: Other Status: NEW Version: 1.3.99.3 Component: SyncEvolution Product: SyncEvolution Currently the user of the PIM API only gets a single "success/failure" boolean back from the SyncPeer call. It is desirable to get more information, for example to determine whether a copy of the local data needs to be refreshed. It is hard to determine in the implementation what has changed (text, photos, or both). This might have to be added later, so the proposed API change should allow conveying that information without another API change. Only changing the return code of SyncPeer is not enough. The "incremental PHOTO download" issue (bug #59551) suggests to do the initial sync (and just the initial sync!) in two phases: first just the text, then with photos. The problem with the SyncPeer API is that the method will only return after the second phase. There is no way to notify the caller that the first phase is over and that running a search will now produce results. This defeats the purpose of the incremental photo download. So here's the proposed API change and a new signal for the incremental case: dict SyncPeer(string uid) Retrieve contacts from the peer and ensure that the local cache is identical to the address book of the peer. The call returns once the operation is complete. Only if there was no error can the caller assume that the cache is up-to-date. In this case, a string to variant dictionary is returned which provided additional information about the sync. If the call fails, no dictionary is returned and the local cache may or may not be up-to-date. SyncEvolution will return a dict with the following entries: "modified": boolean - data was modified "added" : integer - number of new contacts "modified" : integer - number of updated contacts "removed" : integer - number of deleted contacts Service: org._01.pim.contacts Interface: org._01.pim.contacts.Manager Object path: /org/01/pim/contacts ... Signals: void SyncProgress(string uid, string event, dict data) Provides information about a running sync for the peer with the given "uid". The "event" string describes what happened and the "data" dictionary provides further information about it with a mapping from event specific string keys to variants as value. The data dict has the same keys as for SyncPeer. For SyncEvolution, I could emit (in this order): started modified* done Note that "modified" may occur zero or more times. In the upcoming implementation, it would get emitted at most two times, at the end of each phase. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.