This is two-fold: - "percent complete" over the entire sync (including two-phase syncs with text-only followed by photo sync) - to be used in a UI as progress indicator - "add/updated/removed" contacts while the sync runs - to be used by other components instead of polling for changes Both notifications need to be sent out at a smooth rate, neither too often (overhead) nor too infrequently (which negates the purpose). Once per second?
In practice, phones do not provide a size estimate of the data transfer. Only the number of contacts is known. This n/m items is already used to provide an estimate for the sync. What remains to be done/seen is how well that works for incremental download of photos and adding a PIM Manager API for it.
See bug #70950 comment #1 for an API proposal. Do GetPeerStatus() and the "progress" SyncProgress event make sense? Okay to implement like that?
See also "progress-frequency" and the description of how progress percentage would be implemented.
Eugenio, any comments on the enhanced progress API?
(In reply to comment #4) > Eugenio, any comments on the enhanced progress API? These API are ok as aligned to bug #70950 comment #4. 'sync-cycle' will be very useful. In case of incremental sync. Is the "end of text/beginning of pictures" sync notified?
(In reply to comment #5) > (In reply to comment #4) > > Eugenio, any comments on the enhanced progress API? > > These API are ok as aligned to bug #70950 comment #4. > 'sync-cycle' will be very useful. > > In case of incremental sync. > Is the "end of text/beginning of pictures" sync notified? There is no special event for it. But it can be detected as the 'sync-cycle' transition from 'incremental-text' to 'incremental-picture'. Is that enough?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Eugenio, any comments on the enhanced progress API? > > > > These API are ok as aligned to bug #70950 comment #4. > > 'sync-cycle' will be very useful. > > > > In case of incremental sync. > > Is the "end of text/beginning of pictures" sync notified? > > There is no special event for it. But it can be detected as the 'sync-cycle' > transition from 'incremental-text' to 'incremental-picture'. Is that enough? Yes it is enough, If possible (not strictly indispensable) an extra event triggered in the end of the text sync with some kind of "end-text" notification can give a better understanding about the exact moment the addressbook can be browsed.
I would like to suggest a slight change in the proposed API. The purpose of the regular "progress" event is a) a heartbeat ensuring that the sync really runs b) provide completion information (percent) c) inform recipient when database got changed shortly after the change a) and b) are okay, but c) is unnecessarily difficult. As it stands now, a receiver of the "progress" event must keep track of the "added", "updated", "removed" values and compare against the new values. If any value increases, the database was modified. To illustrate that, here's a text representation of a sync where a contact gets first added (text-only) then later updated (with its photo): 00:00/+00:00.005: started = {} 00:01/+00:01.291: | | 0.0% {'updated': 0, 'removed': 0, 'modified': False, 'added': 0} 00:09/+00:08.273: | | 0.0% {'updated': 0, 'removed': 0, 'modified': False, 'added': 0} 00:17/+00:07.554: |---> | 21.0% {'updated': 0, 'removed': 0, 'modified': True, 'added': 1} 00:21/+00:04.361: modified = {'updated': 0, 'removed': 0, 'modified': True, 'added': 1} 00:21/+00:00.000: |---------> | 50.0% {'updated': 0, 'removed': 0, 'modified': True, 'added': 1} 00:24/+00:02.988: |---------> | 50.8% {'updated': 1, 'removed': 0, 'modified': True, 'added': 1} .... 02:15/+00:02.993: |------------------> | 98.0% {'updated': 1, 'removed': 0, 'modified': True, 'added': 1} 02:15/+00:00.217: |--------------------| 100.0% {'updated': 1, 'removed': 0, 'modified': True, 'added': 1} 02:15/+00:00.016: modified = {'updated': 1, 'removed': 0, 'modified': True, 'added': 1} 02:15/+00:00.008: done = {} I suggest to simplify that. Instead of sending "modified/updated/removed/added", let's just send "modified" as part of "SyncProgress" "progress" events, with a slightly different semantic: - "modified": None - set if the database was modified since the last "progress" event. Detecting the exact moment when a change is made can be hard, so the implementation may err on the side of caution and signal a change more often than strictly necessary. The recipient must check the database anyway to determine what changed. With that change, the above trace becomes: 00:00/+00:00.005: started = {} 00:01/+00:01.291: | | 0.0% {} 00:09/+00:08.273: | | 0.0% {} 00:17/+00:07.554: |---> | 21.0% {'modified': None} 00:21/+00:04.361: modified = {'updated': 0, 'removed': 0, 'modified': True, 'added': 1} 00:21/+00:00.000: |---------> | 50.0% {} 00:24/+00:02.988: |---------> | 50.8% {'modified': None} .... 02:15/+00:02.993: |------------------> | 98.0% {} 02:15/+00:00.217: |--------------------| 100.0% {} 02:15/+00:00.016: modified = {'updated': 1, 'removed': 0, 'modified': True, 'added': 1} 02:15/+00:00.008: done = {} Okay?
> > Okay? Yes, it is fine.
Implemented as part of syncevolution-1-3-99-7-20140203.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.