Bug 72114 - enhanced progress notifications
Summary: enhanced progress notifications
Status: RESOLVED FIXED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: PIM Manager (show other bugs)
Version: 1.4
Hardware: Other All
: high enhancement
Assignee: Patrick Ohly
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 70950
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-28 10:15 UTC by Patrick Ohly
Modified: 2014-02-14 10:34 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Ohly 2013-11-28 10:15:52 UTC
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?
Comment 1 Patrick Ohly 2013-11-28 10:30:48 UTC
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.
Comment 2 Patrick Ohly 2014-01-15 13:41:42 UTC
See bug #70950 comment #1 for an API proposal.

Do GetPeerStatus() and the "progress" SyncProgress event make sense? Okay to implement like that?
Comment 3 Patrick Ohly 2014-01-15 13:43:13 UTC
See also "progress-frequency" and the description of how progress percentage would be implemented.
Comment 4 Patrick Ohly 2014-01-17 09:16:09 UTC
Eugenio, any comments on the enhanced progress API?
Comment 5 Eugenio Parodi 2014-01-17 09:53:52 UTC
(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?
Comment 6 Patrick Ohly 2014-01-17 09:58:30 UTC
(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?
Comment 7 Eugenio Parodi 2014-01-17 10:14:14 UTC
(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.
Comment 8 Patrick Ohly 2014-01-24 07:16:50 UTC
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?
Comment 9 Eugenio Parodi 2014-01-27 17:34:14 UTC
> 
> Okay?

Yes, it is fine.
Comment 10 Patrick Ohly 2014-02-14 10:34:37 UTC
Implemented as part of syncevolution-1-3-99-7-20140203.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.