On Thu, 2010-03-25 at 18:13 +0000, Frederik Elwert wrote:
Am Donnerstag, den 25.03.2010, 14:33 +0100 schrieb Patrick Ohly:
> In terms of feedback, please try out direct sync and automatic sync.
> These are the new features in 1.0 which might still have bugs and
> usability problems.
Since I’m currently moving Genesis from commandline usage to D-Bus
communication (sync/reports done, configuration coming next), I’d like
to know how automatic sync can be used via D-Bus. After a quick look, I
didn’t find it in the docs (but maybe I was looking at the wrong
It's enabled by setting the following sync properties, then starting the
syncevo-dbus-server, or setting them via D-Bus directly. Directly
editing config files while the D-Bus server is running is a loophole -
the server will not detect that (could be added, of course).
# Controls automatic synchronization. Currently,
# automatic synchronization is done by running
# a synchronization at regular intervals. This
# may drain the battery, in particular when
# using Bluetooth!
# Because a peer might be reachable via different
# transports at some point, this option provides
# detailed control over which transports may
# be used for automatic synchronization:
# 0 - don't do auto sync
# 1 - do automatic sync, using whatever transport
# is available
# http - only via HTTP transport
# obex-bt - only via Bluetooth transport
# http,obex-bt - pick one of these
# autoSync = 0
# This is the minimum number of seconds between two
# synchronizations that has to pass before starting
# an automatic synchronization. Can be specified using
# a 1h30m5s format.
# Before reducing this interval, consider that it will
# increase resource consumption on the local and remote
# side. Some SyncML server operators only allow a
# certain number of sessions per day.
# The value 0 has the effect of only running automatic
# synchronization when changes are detected (not
# implemented yet, therefore it basically disables
# automatic synchronization).
# autoSyncInterval = 30M
# An automatic sync will not be started unless the peer
# has been available for this duration, specified in seconds
# or 1h30m5s format.
# This prevents running a sync when network connectivity
# is unreliable or was recently established for some
# other purpose. It is also a heuristic that attempts
# to predict how long connectivity be available in the
# future, because it should better be available long
# enough to complete the synchronization.
# autoSyncDelay = 5M
I can’t promise Genesis will be fully migrated when SyncEvolution 1.0
released, but I’ll try to have the most important parts done, so I could
at least release a preview version.
Once the command line accesses the D-Bus server automatically, even the
command line based Genesis would properly integrate into the system, but
without taking full advantage of it. So it's good to hear that you might
get something working.
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.