[SyncEvolution] Keepalives when syncing

[Patrick Ohly]

On Thu, 2014-02-06 at 04:17 +0100, Ove Kåven wrote:
> Well, it turns out that to prevent the Jolla from suspending itself in 
> the middle of a sync (or more likely, data backup or data diff), I 
> should send some D-Bus message to the MCE daemon at the start of a sync, 
> and then keep sending it regularly until the sync is done, at which 
> point I should send a final message. Here's the interface:
> https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h#L329
> 
> Now where in the SyncEvolution code would it be wise to hook in to do 
> something like that?

Are you using syncevo-dbus-server to run the syncs? Do you want to
enable auto-syncing?

If it's just about preventing suspend during a sync and you want that to
work also when using the command line (syncevolution --daemon=no, or
when D-Bus server was not enabled during compilation), then the
keep-alive ping needs to go into SyncContext::doSync(). You could either
add some code directly before SessionStep() which checks the current
time, or you set up a glib idle timer at the start of doSync() and send
the ping in the idle callback. There is some C++ utility code for that
in src/dbus/server/timeout.h/cpp. Arguably that code should be in
src/syncevo. I can move it before releaseing 1.4.

The approach with an idle callback is better than relying on doSync()
loop iterations, because those won't happen while waiting for a SyncML
message. However, make sure you use libsoup, because only then is the
event loop kept alive while waiting for messages.

Alternatively, one could change src/dbus/server/session.cpp and add code
there which pings MCE while a session is active. This code is guaranteed
to always run because syncevo-dbus-server does not block event
processing. But it won't prevent suspending of "syncevolution
--daemon=no" syncs.

For auto-syncing, more work would be needed in syncevo-dbus-server. The
process sets up timeouts for the time when it might run the next sync. I
assume that these timeouts in glib alone will not wake up the device
from suspend. See src/server/auto-sync-manager.cpp and 
AutoSyncManager::schedule(). There are several runOnce() calls which
must wake up the device.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.