https://bugs.freedesktop.org/show_bug.cgi?id=72112
Patrick Ohly <patrick.ohly(a)gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
SyncEvolution 1.4.99.1 also uses Bluez >= 5.15 Suspend/Resume to really freeze
the transfer.
By default, the new API freezes a sync by stopping to consume data on the
local side of the sync.
In addition, the information that the sync is freezing is now also handed
down to the transport and all sources. In the case of PBAP caching, the local
transport notifies the child where the PBAP source then uses Bluez
5.15 Transfer1.Suspend/Resume to freeze/thaw the actual OBEX transfer.
If that fails (for example, not implemented because Bluez is too old
or the transfer is still queueing), then the transfer gets cancelled
and the entire sync fails. This is desirable for PBAP caching and
Bluetooth because a failed sync can easily be recovered from (just
start it again) and the overall goal is to free up Bluetooth bandwidth
quickly.
--
You are receiving this mail because:
You are on the CC list for the bug.