Solution 1: chunking
====================

One way to achieve suspend/resume would be to split the transfer into chunks.
SyncEvolution then can pause after each chunk. I am not a fan of this, for
several reasons:
Make the chunks to large and suspending will only occur after a noticable delay
(to be tested).
     1. Make them too small and there will be additional overhead (again, to be
tested).
     2. The definition of contact offsets is poor, so when contacts get deleted
in parallel to a transfer, the outcome is unclear. Phones might crash and/or
return incorrect data, leading to duplicates or missing data after the sync.
     3. 
Testing the last scenario with all supported phones would be a huge effort, so
I'd prefer to avoid it.

Solution 2: streaming
=====================

I implemented support for using a named pipe instead of a plain file. In this
case, obexd writes into the pipe and SyncEvolution reads from it. To suspend,
SyncEvolution simply stops reading.

The expectation is that this also stops the actual transfer via Bluetooth
because obexd gets stalled writing the data fairly quickly (buffers in a pipe
are small). This does work, albeit not as gracefully as one would hope. The
transfer does indeed stop and can resume seamlessly later, but obexd freezes
completely in a blocking write() call during that time. In other words, *all*
operations of obexd get "suspended"; it also becomes unresponsive on the D-Bus
session bus.

Streaming has one additional advantage over a plain file: there is no need to
buffer the entire address book in a file. SyncEvolution can (and does) consume
contacts as they come in with plain files and the pipe, but with the file-based
approach it cannot discard the already processed data.

Solution 3: dedicated Bluez API
===============================

The Transfer instance has a Cancel() method. Perhaps Suspend() and Resume() can
be added there, too?

-------------------------------------------------------

My personal preference would be option 2, with writing in obexd changed such
that it can detect full pipes and continue servicing other operations until the
pipe becomes usable again. I prefer that because streaming is more efficient
and thus worthwhile on its own. The next step would be to support fd passing
and thus allow avoiding named pipes in the file system, which are a security
risk (all apps of the user have access) and potential resource leak (in case of
failures).

But ultimately the Bluez maintainers need to weigh in and at least provide
guidance about the pefered approach.