Bug 72114

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.