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.