Patrick Ohly skrev:
On Mo, 2010-03-15 at 11:30 +0000, rustonm2005(a)yahoo.co.uk wrote:
> Just wondered if there was any plan to extend the sync-gui interface
> to allow for a more granular sync frequency (i.e. more than daily)?
I assume you mean the Maemo GUI?
Ove, are you subscribed to this list?
Sure... I thought I had already answered posts there before (that I
wasn't already Cc-ed on)...
> I'm using on a nokia n900 and I'm thinking that it would
> good to have something linked to dbus signals to syncronise a specific
> time period after the last calendar update. Sort of delayed realtim e
> syncing. Only mention it because I'm looking at a wrapper to do this.
We already implemented regular syncs in the core SyncEvolution, much
like Ove has done for the Maemo GUI (apparently - haven't seen it
myself) and Frederik did on the Genesis GUI. Sync frequency is
configurable there. This depends on running the syncevo-dbus-server,
something that Ove probably doesn't do yet in the Maemo package.
Right, they're still based on 0.9. I'm not aware of any immediate need
for switching over to the 1.0 codebase. To do period syncs, the Maemo
frontend just hooks into alarmd, Nokia's crond-on-steroids thing.
In fact, running off syncevo-dbus-server would currently be a
disadvantage on a device such as the N900. The Maemo frontend
communicates with the N900's Internet Connectivity Daemon, which means:
1) If invoked from alarmd, the frontend asks ICD for an automatic (i.e.,
not user initiated) connection. If the device is not already connected,
the device's system policy will then take effect; if the device's policy
is to automatically connect to the nearest network (and there's one
nearby), the N900 will do so (and then notify the frontend when the
connection is up). If there's no available WLAN and the system settings
forbid automatic connection to GPRS/3G, then ICD will reject the
connection request, and the frontend will abort. (The user may sync
manually later by going into the GUI.)
2) ICD also maintains proxy settings for each configured network. Hence,
when roaming between different WLANs (and 3G), proxy settings may
change. After the ICD has notified the frontend that the connection is
up, the frontend then asks ICD for the current proxy settings, and if
any, provides them on the syncevolution command line using
--sync-property. The sync then starts.
3) After the sync, the connection is released. If nobody else was using
the connection, the device may then disconnect from the Internet again
at its leisure, saving power.
4) Also, alarmd hooks into the N900's power management system. The
alarmd is capable of waking the N900 from deep sleep, it can even turn
the device on at a preset time if powered off (although I don't use this
feature, of course). I'm not sure whether the N900 could enter deep
sleep if syncevo-dbus-server was running in the background, perhaps it
could, but in any case, using alarmd I *know* that none of the user's
precious battery power (or similarly precious RAM) is wasted in between
syncs. (Of course, once alarmd starts the frontend, some extra CPU
cycles may be spent running Python and stuff, but that's at least better
than any potential invisible battery drain between syncs, IMO.)
Perhaps it would be possible to patch in the ICD interface into
syncevolution so that its dbus-server thing could handle it without
needing the frontend, but it'd probably not be trivial, and I won't have
time to do anything like that anytime soon. So for now, on the N900, the
Maemo frontend's autosync is functionally superior to syncevolution's
own, and probably will be for a while.
The only complaint people seem to have about the frontend is that the
Maemo GUI doesn't allow anything but daily sync, but that's only a
problem with the user interface, not with the codebase. And the server
features etc of 1.0 is probably redundant on the N900. So I just haven't
seen the need for trying to port 1.0 at this time.
If people really want the Maemo GUI to support other sync periods than
daily, they should feel free to send me patches. I only need a daily
sync myself, so I might not get around to do it. And besides, I'm not
sure what a more flexible GUI should look like, at least without making
it much messier. For a patch, you only need to add the configuration
GUI, I can probably implement the alarmd magic (yes, the alarmd
interface is confusing and poorly documented). And this GUI change
would, of course, be needed regardless of whether the clock it
controlled was named syncevo-dbus-server or alarmd...