[SyncEvolution] Keepalives when syncing

[Patrick Ohly]

On Thu, 2014-02-06 at 21:21 +0100, Ove Kåven wrote:
> 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.

Syncing is meant to piggyback on an Internet connection created for some
other purpose (enabling Wifi, plugging into an Ethernet), but yes,
that's a model that does not work so well for a phone.

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

Agreed. autoSyncDelay=0 could be interpreted as such a new "don't wait
for Internet, enable it when the time for a sync comes" mode. The
ConnmanClient class in connman-client.h/cpp is the C++ class which talks
to org.connman.Manager via D-Bus. It could be extended to also allow
calling these extra methods.

However, an abstract API that the ConnmanClient and (perhaps later) the
NetworkManager class can implement would be better. The place that
prevents suspend could also use that abstract API to ensure Internet
connectivity.

BTW, reliably detecting whether a sync config needs Internet is not that
easy. There's no information that "backend = caldav" needs Internet
while "backend = evolution-contacts" does not (normally; it might need
Internet, depending on which database is used...). Local syncs involving
just two different local databases on both sides will not. It's probably
easier to just continue ignoring this.

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

Basically it starts with Session::sync(), continues in Session::sync2()
and finishes with Session::dbusResultCb().

Having to split up sync() because of one asynchronous call in the middle
is not nice. This is one thing which, for example, Vala does better than
C++. At least in C++, we can pass extra parameters via boost::bind()
without having to define our own structs, as in C.

> Which methods are the best ones to fiddle with here?

Session::sync() and Session::dbusResultCb().

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

Right, that's what I meant. I should have said "runOnce() should wake up
the device, but must be extended to actually do so".

On Fri, 2014-02-07 at 01:25 +0100, Ove Kåven wrote:
> Come to think of it: Regardless of how SyncEvolution uses Connman (even 
> if just checking if the network is online, like it does now), perhaps 
> there should be a config option for only autosyncing when a WLAN 
> connection is in use, never over a cellular network (which could be 
> expensive, depending on the data plan and whether the user is roaming).

Yes, that would make sense.

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