[SyncEvolution] Keepalives when syncing

[Ove Kåven]

Den 06. feb. 2014 15:50, skrev 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?

Yes, I'm using syncevo-dbus-server. (If someone uses --daemon=no, they 
probably don't need this stuff anyway.)

I'm allowing autosyncing, but perhaps that's another thing I should ask 
you about: currently, SyncEvolution's autosync delay setting seems 
designed for computers that connect to the Internet in the background 
whenever they are powered on. But that doesn't necessarily work so well 
for devices that connect to the Internet on demand.

SailfishOS uses Connman. It seems that if an app wants an Internet 
connection, it can start a Connman session and send a "Connect" message 
(http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/session-api.txt?id=HEAD). 
I think Connman also provides proxy settings and such.

(Nokia's N900 and N9 devices use a proprietary Nokia Internet 
Connectivity Daemon, but the model is very similar. Apps should tell the 
ICD whenever they want an Internet connection.)

Although the Jolla phones do try to keep an Internet connection active 
as long as the phone is in use, they don't try very hard when the screen 
is off and the phone suspended. Thus, for autosync to work reliably 
while the screen is off (which is probably less annoying for the user 
than only syncing when the phone is in use), a different model is 
needed: when SyncEvolution decides that it's time for a sync, it tells 
MCE to prevent a suspend, then it tells Connman to establish an Internet 
connection, and waits for a response; if successful, start a sync; when 
finished, tell Connman that an Internet connection is no longer needed, 
and tell MCE that it's OK to go back to suspend.

> 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.

No, I'm not using libsoup. That's not a standard library on these 
devices. (Though I know libcurl has a progress callback that's called at 
least every second, which could perhaps be used for such things.) But 
since I don't care about the --daemon=no case, I guess this is nothing 
to worry about.

> 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.

Well, it's a possibility. The logic isn't so easy to follow, though. 
Which methods are the best ones to fiddle with here?

> 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.

No, glib timeouts aren't enough. To schedule a wakeup from deep suspend 
you're supposed to talk to the IPHB service or something. (I think it's 
a service that ensures that if several tasks need to wake up on similar 
schedules, then it tries to wake them all up at the same time, so that 
the CPU doesn't have to be powered up any longer than necessary. Of 
course, the tasks still need to talk to the MCE to keep the CPU powered 
for as long as they need it to be.)