Patrick Ohly changed bug 72114
What Removed Added
Status ASSIGNED NEEDINFO

Comment # 8 on bug 72114 from
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?


You are receiving this mail because: