Skip to content

{ Category Archives } Uncategorized

SyncEvolution 1.4 released

The 1.4 release of SyncEvolution replaces 1.3.2 as the stable, supported release.

1.4 is the first stable version with the in-vehicle infotainment (IVI) PIM Manager included. GENIVI Diagnostic Log and Trace (DLT) is also supported. For more information about this aspect of SyncEvolution, see the PBAP and PIM entries in the 1.3.99 release notes and these Automotive Linux Summit slides.

The biggest change for normal Linux users is Google CalDAV/CardDAV
authentication with OAuth2. These are the open protocol that Google
currently supports and thus the recommended way of syncing with
Google, replacing ActiveSync and SyncML (both no longer available to
all Google customers).

SyncEvolution 1.3.99.7 released

This the final release candidate for 1.4. No further changes planned unless
new problems are found.

SyncEvolution 1.3.99.5 released

SyncEvolution now supports Google CalDAV/CardDAV with OAuth2
authentication. These are the open protocol that Google currently
supports and thus the recommended way of syncing with Google,
replacing ActiveSync and SyncML (both no longer available to all
Google customers).

Support for Google CardDAV is new. Because of a vCard encoding issue
on the server side, spaces in long notes may get removed. Like
Evolution, SyncEvolution does not yet support some of the advanced
features of the server, in particular custom labels for phone numbers,
emails and addresses. Likewise, some client properties are not
supported by the server: CALURI, CATEGORIES, FBURL, GEO and ROLE are
not supported. Of ORG, only the first two components are supported.
Currently, properties not supported by one side get lost in a full
roundtrip sync.

SyncEvolution depends on external components for OAuth2. It can be
compiled to use gSSO or GNOME Online Accounts. GNOME Online
Accounts >= 3.10 works out of the box for CalDAV and CardDAV, 3.8 only
for CardDAV (but the GNOME Online Accounts binary can be patched to
also support CalDAV), anything older than 3.8 does not
work. Support for Ubuntu Online Accounts should not be hard to add,
but is not available yet.

Evolution >= 3.6 is not supported by the binaries on syncevolution.org. On systems with a more recent Evolution, SyncEvolution must be compiled from source.

Details:

  • GTK UI: fixed two crashes – running a sync with no service selected
    and a 64 bit pointer problem recently discovered by Tino Keitel when
    compiling the Debian package with -fPIE.

  • password handling: fix usage of GNOME Keyring and KWallet (FDO #66110)

    When clients like the GTK sync-ui stored a password, it was always
    stored as plain text in the config.ini file by the
    syncevo-dbus-server. The necessary code for redirecting the password
    storage in a keyring (GNOME or KWallet) simply wasn’t called in that
    case.

    The command line tool, even when using the D-Bus server to run the
    operation, had the necessary code active and thus was not affected.
    Now all SyncEvolution components use the same default: use safe
    password storage if either GNOME Keyring or KWallet were enabled
    during compilation, don’t use it if not.

    Fixing this revealed other problems, like not being able to store
    certain passwords that lacked the necessary lookup criteria (like
    syncURL and/or username). To address this, the lookup criteria where
    extended and a new check was added to avoid accidentally removing
    other passwords. As a result, it may be possible that SyncEvolution
    no longer finds passwords that were stored with older versions of
    SyncEvolution. In such a case the passwords must be set again.

  • GNOME: clean up keyring access and require libgnome-keyring >= 2.20

    The updated error messages now always include information about the
    password and libgnome-keyring error texts.

    A workaround is used for the “Error communicating with
    gnome-keyring-daemon” problem that started to appear fairly
    frequently in the automated testing once the keyring was actually
    used. The problem shows up with some additional debug messages:

    Gkr: received an invalid, unencryptable, or non-utf8 secret
    Gkr: call to daemon returned an invalid response: (null).(null)()

    It seems that sometimes setting up a session with GNOME keyring
    fails such that all further communication leads to decoding problem.

    There is an internal method to reset the session, but it cannot be
    called directly. As a workaround, fake the death of the GNOME
    keyring daemon and thus trigger a reconnect when retrying the GNOME
    keyring access. This is done by sending a D-Bus message, which will
    also affect other clients of GNOME keyring, but hopefully without
    user-visible effects.

  • config: enhanced password handling

    It is possible to configure a plain username/password combination
    once in SyncEvolution and then use references to it in other
    configurations, instead of having to set (and update) the
    credentials in different places. This is useful in particular with
    WebDAV, where credentials had to be repeated several times (target
    config, in each database when used as part of SyncML) or when using
    a service which requires several configs (Google via SyncML and
    CalDAV).

    To use this, create a sync config for a normal peer or a dedicated
    config just for the credentials, with “username/password/syncURL”
    set. The “syncURL” must be set to something identifying the peer if
    GNOME Keyring is used for the password storage.

    Then set “username”, “databaseUser” and “proxyUser” properties to
    “id:” and all read and write access
    to those properties will be redirected by SyncEvolution into that
    other configuration. This even works in the GTK UI.

    For user names which contain colons, the new “user:” format
    must be used. Strings without colons are assumed to be normal user
    names, so most old configurations should continue to work.

  • signon: new backend using libgsignond-glib + libaccounts-glib

    The code works with gSSO (https://01.org/gsso). With some tweaks to
    the configure check and some ifdefs it probably could be made to work
    with Ubuntu Online Accounts.

    The code depends on an account accessible via libaccounts-glib which
    has a provider and and (optionally) services enabled for that
    provider. It is not necessary that the account already has a signon
    identity ID, the backend will create that for the provider (and thus
    shared between all services) if necessary.

    Therefore it is possible to use the ag-tool to create and enable the
    account and services. Provider and service templates are in the next
    commit.

  • WebDAV: support OAuth2

    If given an authentication configuration which can handle OAuth2,
    then OAuth2 is used instead of plain username/password
    authentication.

  • WebDAV: support Google CardDAV, break Yahoo

    Google CardDAV has one peculiarity: it renames new contacts during PUT without
    returning the new path to the client. See also
    http://lists.calconnect.org/pipermail/caldeveloper-l/2013-July/000524.html

    SyncEvolution already had a workaround for that (PROPGET on old path, extract
    new path from response) which happened to work. This workaround was originally
    added for Yahoo, which sometimes merges contacts into existing ones. In
    contrast to Yahoo, Google really seems to create new items.

    Without some server specific hacks, the client cannot tell what happened.
    Because Google is currently supported and Yahoo is not, let’s change the
    hard-coded behavior to “renamed items are new”.

  • WebDAV: started testing with owndrive.com = OwnCloud

  • GOA: get OAuth2 tokens out of GNOME Online Accounts

    “username = goa:…” selects an account in GOA and retrieves the
    OAuth2 token from that.

    The implementation uses the GOA D-Bus API directly, because our C++
    D-Bus bindings are easier to use and this avoids an additional library
    dependency.

  • PIM: fix UID usage in sync.py example

    Using the underscore in the UID has been wrong all along, it only
    happened to work because UID sanity checking was missing. After adding
    it, the example broke.

    Now simply remove the colon. It makes the UID less readable, but it
    doesn’t have to be, and ensures that file names and database names
    contain the UID as-is.

  • PIM: if busy, don’t shut down

    While there are sessions pending or active, the server should not shut down.
    It did that while executing a long-running PIM Manager SyncPeer() operations,
    by default after 10 minutes.

    This was not a problem elsewhere because other operations are associated with
    a client, whose presence also prevents shutdowns. Perhaps PIM Manager should
    also track the caller and treat it like a client.

  • PBAP: do not end Bluez5 transfer prematurely

    A transfer was marked as finished prematurely when encountering the
    “active” Status value, which can happen for longer transfers.

  • PBAP: add support for obexd 0.48

    obexd 0.48 is almost the same as obexd 0.47, except that it dropped
    the SetFilter and SetFormat methods in favor of passing a Bluex 5-style
    filter parameter to PullAll.

    SyncEvolution now supports 4, in words, four different obexd
    APIs. Sigh.

  • updated tests

Upgrading from releases <= 1.3.99.4:

If the value of “username/databaseUser/proxyUser” contains a colon,
the “user:” prefix must be added to the value, to continue treating it
like a plain user name and not some reference to an unknown identity
provider (like “id:”, “goa:”, “signon:”, etc.).

The lookup of passwords in GNOME Keyring was updated slightly in
1.3.99.5. It may be necessary to set passwords anew if the old one is
no longer found.

Upgrading from release 1.2.x:

The sync format of existing configurations for Mobical (aka Everdroid)
must be updated manually, because the server has encoding problems when
using vCard 3.0 (now the default for Evolution contacts):
syncevolution –configure \
syncFormat=text/x-vcard \
mobical addressbook

The Funambol template explicitly enables usage of the
“refresh-from-server” sync mode to avoid getting throttled with 417
‘retry later’ errors. The same must be added to existing configs
manually:
syncevolution –configure \
enableRefreshSync=TRUE \
funambol

Upgrading from releases before 1.2:

Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. Releases >= 1.2
automatically migrates configurations. The old configurations
will still be available (see “syncevolution –print-configs”) but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.

Source, Installation, Further information

Source code bundles for users are available in
http://downloads.syncevolution.org/syncevolution/sources
and the original source is the git repositories.

i386, lpia and amd64 binaries for Debian-based distributions are
available via the “unstable” syncevolution.org repository. Add the
following entry to your /apt/source.list:

Then install “syncevolution-evolution”, “syncevolution-kde” and/or
“syncevolution-activesync”.

These binaries include the “sync-ui” GTK GUI and were compiled for
Ubuntu 10.04 LTS (Lucid), except for “syncevolution-activesync” which
depends on libraries in Debian Squeeze, for example EDS 3.4.

Older distributions like Debian 4.0 (Etch) can no longer be supported
with precompiled binaries because of missing libraries, but the source
still compiles when not enabling the GUI (the default).

The same binaries are also available as .tar.gz and .rpm archives in
the download directories. In contrast
to 0.8.x archives, the 1.x .tar.gz archives have to be unpacked and the
content must be moved to /usr, because several files would not be found
otherwise.

After installation, follow the getting started steps. More specific HOWTOs can be found in the Wiki.

SyncEvolution 1.1.99.5 “beyond SyncML” released

Release 1.1.99.5 is the first release candidate for 1.2. It has gone
through a long stabilization period and thus is suitable for normal users.

The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development.

Changes 1.1.1 -> 1.1.99.5

The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development. These protocols are implemented as backends
which are combined with other backends by SyncEvolution in a so called
“local sync”. The GTK sync-ui does not yet support configuring
non-SyncML protocols. See the README and man page for more information
on how to use the new feature via the command line.

Properties not supported by SyncML servers can now be preserved
locally in two-way synchronization (BMC #15030). This depends on
information about what properties a SyncML server supports (”CtCap”),
which is typically not provided by servers. SyncEvolution contains a
copy of that information for Google Contacts (BMC #15029).

Akonadi backend and KWallet support were merged. They are not included
yet in syncevolution.org binaries. To use them compile from source.

The configuration format was updated to solve a conceptual problem
inherited with the legacy property names: the “type” property had
multiple, sometimes conflicting roles. For example, setting the
preferred data format for sync with one peer might have changed the
backend selection for some other peer (BMC #1023). Now
“backend/databaseFormat/syncFormat/forceSyncFormat” replace
“type”. “type” is still accepted by the command line as alias.

Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. In contrast to
earlier, more experimental releases in the 1.2 series, 1.1.99.5 and
later automatically migrate configurations. The old configurations
will still be available (see “syncevolution –print-configs”) but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.

Other changes:

  • a problem with enabling release mode required replacing 1.1.99.5
    with a fixed 1.1.99.5a release
  • syncevo-http-server was enhanced considerably. See the HTTP server HOWTO
  • support NetworkManager API >= 0.9 (BMC #19470)
  • Sync mode is recorded when running in SyncML server mode (BMC #2786).
  • syncevo-dbus-server automatically stops when some of its libraries
    are updated and restarts if auto-syncing is on (BMC #14955).
  • Using the –sync-property and –source-property command line options is
    optional, just specifying the property assignment is enough.
  • Added support for Buteo, mKCal and QtContacts in MeeGo.
    Buteo and mKCal were removed again from MeeGo, so the code
    is obsolete. The QtContacts backend may be still be useful
    to access items via that API, but for syncing on MeeGo
    the normal EDS backend is used since MeeGo reverted back
    to EDS as PIM storage.
  • code cleanup and various minor fixes/improvements, see ChangeLog

Source, Installation, Further information

Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources

i386, amd64 and lpia binaries for Debian-based distributions are available via the “unstable” syncevolution.org repository. Add the following entry to your /apt/source.list, then install “syncevolution-evolution”:

These binaries include the “sync-ui” GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default).

The same binaries are also available as .tar.gz and .rpm archives in http://downloads.syncevolution.org/syncevolution/evolution. In contrast to 0.8.x archives, the 1.0 .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise.

After installation, follow the getting started steps.

SyncEvolution 1.1.99.5 “beyond SyncML” released

Release 1.1.99.5 is the first release candidate for 1.2. It has gone
through a long stabilization period and thus is suitable for normal users.

The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development.

Changes 1.1.1 -> 1.1.99.5

The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development. These protocols are implemented as backends
which are combined with other backends by SyncEvolution in a so called
“local sync”. The GTK sync-ui does not yet support configuring
non-SyncML protocols. See the README and man page for more information
on how to use the new feature via the command line.

Properties not supported by SyncML servers can now be preserved
locally in two-way synchronization (BMC #15030). This depends on
information about what properties a SyncML server supports (”CtCap”),
which is typically not provided by servers. SyncEvolution contains a
copy of that information for Google Contacts (BMC #15029).

Akonadi backend and KWallet support were merged. They are not included
yet in syncevolution.org binaries. To use them compile from source.

The configuration format was updated to solve a conceptual problem
inherited with the legacy property names: the “type” property had
multiple, sometimes conflicting roles. For example, setting the
preferred data format for sync with one peer might have changed the
backend selection for some other peer (BMC #1023). Now
“backend/databaseFormat/syncFormat/forceSyncFormat” replace
“type”. “type” is still accepted by the command line as alias.

Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. In contrast to
earlier, more experimental releases in the 1.2 series, 1.1.99.5 and
later automatically migrate configurations. The old configurations
will still be available (see “syncevolution –print-configs”) but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.

Other changes:

  • a problem with enabling release mode required replacing 1.1.99.5
    with a fixed 1.1.99.5a release
  • syncevo-http-server was enhanced considerably. See the HTTP server HOWTO
  • support NetworkManager API >= 0.9 (BMC #19470)
  • Sync mode is recorded when running in SyncML server mode (BMC #2786).
  • syncevo-dbus-server automatically stops when some of its libraries
    are updated and restarts if auto-syncing is on (BMC #14955).
  • Using the –sync-property and –source-property command line options is
    optional, just specifying the property assignment is enough.
  • Added support for Buteo, mKCal and QtContacts in MeeGo.
    Buteo and mKCal were removed again from MeeGo, so the code
    is obsolete. The QtContacts backend may be still be useful
    to access items via that API, but for syncing on MeeGo
    the normal EDS backend is used since MeeGo reverted back
    to EDS as PIM storage.
  • code cleanup and various minor fixes/improvements, see ChangeLog

Source, Installation, Further information

Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources

i386, amd64 and lpia binaries for Debian-based distributions are available via the “unstable” syncevolution.org repository. Add the following entry to your /apt/source.list, then install “syncevolution-evolution”:

These binaries include the “sync-ui” GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default).

The same binaries are also available as .tar.gz and .rpm archives in http://downloads.syncevolution.org/syncevolution/evolution. In contrast to 0.8.x archives, the 1.0 .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise.

After installation, follow the getting started steps.

SyncEvolution 1.1.99.5 “beyond SyncML” released

Release 1.1.99.5 is the first release candidate for 1.2. It has gone
through a long stabilization period and thus is suitable for normal users.

The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development.

Changes 1.1.1 -> 1.1.99.5

The major new feature of the 1.2 release is support for non-SyncML
protocols in general and CalDAV/CardDAV in particular. ActiveSync
support is in development. These protocols are implemented as backends
which are combined with other backends by SyncEvolution in a so called
“local sync”. The GTK sync-ui does not yet support configuring
non-SyncML protocols. See the README and man page for more information
on how to use the new feature via the command line.

Properties not supported by SyncML servers can now be preserved
locally in two-way synchronization (BMC #15030). This depends on
information about what properties a SyncML server supports (”CtCap”),
which is typically not provided by servers. SyncEvolution contains a
copy of that information for Google Contacts (BMC #15029).

Akonadi backend and KWallet support were merged. They are not included
yet in syncevolution.org binaries. To use them compile from source.

The configuration format was updated to solve a conceptual problem
inherited with the legacy property names: the “type” property had
multiple, sometimes conflicting roles. For example, setting the
preferred data format for sync with one peer might have changed the
backend selection for some other peer (BMC #1023). Now
“backend/databaseFormat/syncFormat/forceSyncFormat” replace
“type”. “type” is still accepted by the command line as alias.

Old configurations can still be read. But writing, as it happens
during a sync, must migrate the configuration first. In contrast to
earlier, more experimental releases in the 1.2 series, 1.1.99.5 and
later automatically migrate configurations. The old configurations
will still be available (see “syncevolution –print-configs”) but must
be renamed manually to use them again under their original names with
older SyncEvolution releases.

Other changes:

  • a problem with enabling release mode required replacing 1.1.99.5
    with a fixed 1.1.99.5a release
  • syncevo-http-server was enhanced considerably. See the HTTP server HOWTO
  • support NetworkManager API >= 0.9 (BMC #19470)
  • Sync mode is recorded when running in SyncML server mode (BMC #2786).
  • syncevo-dbus-server automatically stops when some of its libraries
    are updated and restarts if auto-syncing is on (BMC #14955).
  • Using the –sync-property and –source-property command line options is
    optional, just specifying the property assignment is enough.
  • Added support for Buteo, mKCal and QtContacts in MeeGo.
    Buteo and mKCal were removed again from MeeGo, so the code
    is obsolete. The QtContacts backend may be still be useful
    to access items via that API, but for syncing on MeeGo
    the normal EDS backend is used since MeeGo reverted back
    to EDS as PIM storage.
  • code cleanup and various minor fixes/improvements, see ChangeLog

Source, Installation, Further information

Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources

i386, amd64 and lpia binaries for Debian-based distributions are available via the “unstable” syncevolution.org repository. Add the following entry to your /apt/source.list, then install “syncevolution-evolution”:

These binaries include the “sync-ui” GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default).

The same binaries are also available as .tar.gz and .rpm archives in http://downloads.syncevolution.org/syncevolution/evolution. In contrast to 0.8.x archives, the 1.0 .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise.

After installation, follow the getting started steps.

The state of syncing in open source

There have been two blog posts recently who point out that data synchronization using open source tools still doesn’t work as well as it should:

As someone who has worked hard on making synchronization suck less I can’t let this stand without commenting… in particular not when SyncEvolution is mentioned as not being reliable! ;-)

Nitpicking

First let me point out some factual mistakes in Adam’s post: “Maemo’s whole synchronization story” has never been based on SyncEvolution. SyncEvolution is an add-on, supported entirely on a volunteer basis by Ove Kaveh on the device. If people do not get help for SyncEvolution in the Maemo forums, then I can’t do anything about it because I don’t have the time to keep up with everything that is said (or asked) on the web about SyncEvolution. It’s up to the Maemo community to help their peers. SyncEvolution on Linux to N900 broken somewhere outside of SyncEvolution (device, Bluetooth stack) and without support by Nokia for their closed-source sync component on the device I don’t see much chances to fix it, short of some Bluetooth experts getting involved.

The statements about MeeGo are also incorrect. Evolution Data Server was not the preferred PIM storage for MeeGo 1.2 until recently, so depending on it for CalDAV/CardDAV support was not an option. Adam points to a bug report where I captured some thoughts around the technical aspects. Perhaps this was too brief to be understand without context, but I still think that the arguments and conclusion are valid. More on that below.

What exactly is the complaint?

Adam tried SyncEvolution with Horde and eGroupware. Other people were
able to get these combinations working, for example just a few days
ago George Runelli with
eGroupware
. It
seems to depend a lot on the exact setup on the server side. I had
offered Adam to help with diagnosing his problem with Horde
(unexpected slow syncs), but he never replied to my email.

I’m still convinced that the problem is not in SyncEvolution, but
rather on the server side, because SyncEvolution works fine with a
variety of other SyncML servers (Funambol, Memotoo, Synthesis,
Mobical, to name just those that I test with nightly). It is not
SyncEvolution’s fault that the open source groupwares seem to have
less stable SyncML support.

I tried to work with Horde and eGroupware developers a while back when
I started with SyncEvolution. I had a hard time getting anyone to
reply to my questions and emails, even when contacting the original
developers directly. If the situation is different today, then I’d be
happy to restart that effort.

I’m not sure what kind of problem Matěj had with SyncEvolution. He
doesn’t say in his blog post, only that it does not allow him to
reliably sync with his server running Zarafa. I’m not surprised. To
the best of my knowledge, the two are unable to synchronize against
each other by design, because SyncEvolution is based on SyncML and
Zarafa on ActiveSync. So is the complaint that SyncEvolution uses an
open protocol and not a patent-encumbered proprietary protocol?

Proposed solutions

Adam then continues to suggest that the data synchronization model
itself is flawed and should be replaced with client/server model where
changes are always stored on the server immediately, as in Evolution’s
CalDAV and CardDAV backends. This became more clear in an email
discussion after he contacted me regarding his blog post.

The key difference is this:

  • True synchronization allows offline modification of the data.
  • Capable devices by design store a complete copy of the data, without depending on one particular server to remain online.

Adam argued that a client/server model can be combined with caching of
items and changes. But then the client/server model becomes
synchronization and must deal with the same kind of problems that it was meant to avoid, like
conflicts between items on client and server. Adam later
said

that changes that cannot be stored anymore should simply be
discarded. That doesn’t sound like a very useful approach, because
users won’t be able to remember what changes might have been lost and
if they do, would most likely be forced to redo them manually. PIM data is
more complex then plain text, so the merge strategies that programers know
how to use with source code and revision control systems do not apply.
Normal users will be even more challenged.

The point about not depending on a central server is important,
too. In the SyncML world we have recently seen that ScheduleWorld shut
down. No data was lost, because by design all users always had a full
copy of their data on their own storage. The same can’t be said for
all the popular Web 2.0 cloud services…

My devices are not always online, for practical and economical
reasons. Therefore I want the ability to make changes while offline
and will continue to work on the more capable model.

SyncML

One other aspect is the question whether the data synchronization
model itself is flawed, just some protocols implementing it, or only
specific implementations of these protocols.

I think the approach itself is sound and useful. Adam’s own
observation that other implementations of the concept seem to work
better confirms that.

But SyncML definitely has its flaws, both in the protocol itself
and in implementations. SyncML tries to be too
flexible for its own good. It allows the implementation of very dumb devices. The
downside is an increased complexity on the server side.

Because of its open nature, there have been a variety of
implementations with varying degrees of capabilities both in the data
that is supported and in the quality of the protocol implementation
itself. That makes it challenging today to support the whole range of
SyncML capable peers. In that sense, SyncML is a victim of its own success.

The silver lining

I have some hopes today for CalDAV/CardDAV based
synchronization. SyncEvolution 1.2 will have support for that,
natively. A native implementation has the conceptual advantage that it
can use meta data (resource URI + eTag) to speed up change detection,
something that wouldn’t be possible when going through Evolution Data
Server.

CalDAV enforces that each item must have a globally unique ID, which
is a considerable simplification for implementing
synchronization. CardDAV unfortunately still doesn’t.

Good open source implementations exist, for example Apple’s Calendar
server. It passes all of the automated SyncEvolution tests. I also
hear good things about DAViCal; unfortunately I haven’t found the time
to test with it yet. What might be missing in both cases is good
integration into a groupware solution, for those who need that.

ScheduleWorld shut down – R.I.P

End of November, the scheduleworld.com service shut down. As a user
confirmed
later
,
a notification had been sent earlier to paying customers. So the
site is really gone and not just encountering some temporary
problems. There does not seem to be any publicly accessible statement
about the shutdown, hence this blog post.

I have no information about the reasons for discontinuing the
service. The notification to users did not give an explanation
either. My guess is that the business side of the service did
not work out. Syncing is a very challenging, technically difficult
problem. I suspect that many users do not understand how much hard
work goes into it and thus are less willing to pay for it. Then there
is the competition with free services. If users are happy with online
access Google Calendar, why should they bother paying for a
synchronization service? There are reasons (see below), but perhaps not enough users care.

This is really sad, for several reasons.

First, ScheduleWorld offered a technically superior SyncML
implementation for calendar synchronization by supporting the full
iCalendar 2.0 semantic, including UID and
RECURRENCE-ID
. When describing these properties in 2008, I wrote that not supporting them “looks like a rather significant gap
for SyncML-based calendar synchronization compared to proprietary
solutions. Hopefully SyncML server vendors will wake up and do
something about it…” I don’t think they have – or can anyone point
to a SyncML server which supports this today, over one and a half year
later? I’m not aware of any.

Second, although ScheduleWorld used the open source Funambol server
code, none of the extensions or modifications were ever made
available. That’s perfectly compliant with the license of the code that
was used (GPL instead of AGPL as today), but it implies that the ScheduleWorld
source code is now lost and no-one can use or study it.

Third, I believe that storing my data on my own hardware and
synchronizing it via open standards is crucial. ScheduleWorld made
that possible for users who did not want to run their own SyncML
server. With true syncing instead of just online access, data is
available while offline – pretty obvious, but worth spelling out explicitly. When
syncing is based on open standards, users can decide which service
they want to use. They don’t depend on that service to store their data; important,
because any service might go away unexpectedly and take the data with it. With
ScheduleWorld, all data was always and by design also stored locally,
so no data was lost when the site shut down. The same is not true for
many (if not all) of the now popular Web 2.0 services.

Replacements for ScheduleWorld

I’m not sure yet what I should recommend as replacement. Memotoo seems
to be popular, but it does not support UID/RECURRENCE-ID semantic, so
there are issues when synchronizing complex iCalendar 2.0 calendar
data
. For advanced users
the SyncEvolution server
mode
might be
an alternative, but it is in a very rough state at this point and
requires a publicly accessible machine for anytime, anywhere
synchronization.

SyncEvolution 1.0.1 released

SyncEvolution 1.0.1

A bug fix release. The main reason for releasing it is that
SyncEvolution 1.0 no longer worked on recent distros (Fedora Core 13,
Debian testing) because of a name clash between the Bluez D-Bus
utility code and recent glib.

Details:

  • compile fix for FC 13 (and possibly others): use private copy of gdbus (BMC #3556)

  • sync-ui: prevent overwriting device configs by accident (BMC #3566,BMC #1194)
    Setting up a phone used the template name as config name and overwrote
    an existing configuration of another phone that was created using that
    same template. Now the code uses the Bluetooth device name as set on the
    device and checks for (less likely) collisions. It also sanitizes the
    name to avoid complicated config names (only relevant when also using
    the command line).

  • syncevo-dbus-server: accept ‘application/vnd.syncml+xml; charset=UTF-8′ for starting an HTTP session (BMC #3554)
    The redundant charset specification was set by the Funambol
    Thunderbird client. Because of a literal comparison against
    ‘application/vnd.syncml+xml’ the messages were rejected.

  • config fix: operations on non-peer configs failed (BMC #3157)
    When running operations on a non-peer configuration (like –restore @default
    addressbook), the operation fails with
    [ERROR] : type ’select backend’ not supported

  • ZYB.com: service goes away end of June 2010, template removed (BMC #3310)

  • some build (BMC #2586, BMC #3557) and language updates

Source, Installation, Further information

Source snapshots are in
http://downloads.syncevolution.org/syncevolution/sources

i386, amd64 and lpia binaries of 1.0 for Debian-based distributions are available via the “stable” syncevolution.org repository. Add the following entry to your /apt/source.list, then install “syncevolution-evolution”:

These binaries include the “sync-ui” GTK GUI and were compiled for Ubuntu 8.04 LTS (Hardy). Older distributions like Debian 4.0 (Etch) can no longer be supported with precompiled binaries because of missing libraries, but the source still compiles when not enabling the GUI (the default).

The same binaries are also available as .tar.gz and .rpm archives in http://downloads.syncevolution.org/syncevolution/evolution. In contrast to 0.8.x archives, the 1.0 .tar.gz archives have to be unpacked and the content must be moved to /usr, because several files would not be found otherwise.

After installation, follow the getting started steps.

Memotoo

Server with very good support for SyncEvolution, see http://www.memotoo.com/index.php?rub=infoSyncML. It is part of SyncEvolution’s nightly testing and included in the list of configuration templates that come with SyncEvolution.