Skip to content

{ Monthly Archives } December 2010

SyncEvolution “Christmas Edition” 1.1.1 released

Maintenance release, in particular improving syncing with phones.
There was a bug that could cause all kinds of weird behavior after
a failed sync with a phone, so updating is highly recommended.

Changes 1.1 -> 1.1.1

  • Synthesis engine: fixed a corruption issue in internal meta data which
    caused duplicates and other problems in a pretty indeterminstic way;
    apparently caused by failed syncs (BMC #11044).

  • Synthesis engine: recurrence rules with end date now sent correctly to phones (BMC #11241).

    The RRULE property was not encoded correctly previously during the
    iCalendar 2.0 -> vCalendar 1.0 conversion. Events with recurrence count
    were okay. Probably also affected SyncML servers without iCalendar 2.0

    The fix was confirmed to work with Nokia phones. It also helps with Sony Ericsson
    phones, but at least the t700 still has a problem: depending on the phone’s
    time zone, it repeats the event for one day too long (BMC #10092).

  • Synthesis engine: fixed broken time zone information when sending to phone;
    previously that broke sending calendar updates to Nokia phones (BMC #9600).

    iCalendar 2.0 time zone definitions imported from libical were not
    encoded correctly in vCalendar 1.0 items as sent to phones. Nokia
    phones accepted such data when part of a new event, but rejected
    updates of it.

  • Synthesis engine: shorter TZIDs, might help N900 calendar (BMC #6680).

    The shorter TZIDs will be included in iCalendar 2.0 data exported
    by libsyntesis and thus SyncEvolution. This change is motivated primarily
    by the observation that the N900 calendar storage can handle TZID=,
    but not TZID=/

  • ScheduleWorld: disable configuration template because service has shut down.

    The template is only hidden from the GTK sync-ui, but remains in SyncEvolution
    for the time being because it is referenced in several places.

  • Evolution CalDAV: added workaround for “must sync twice” (BMC #10265)

    The Evolution CalDAV backend seems to update its data when closing the
    database, not when opening it. As a result, syncevolution had to be run
    twice to see all data changes. The workaround is to open the database
    twice at the start of the sync. This is done for all calendar databases,
    regardless of which backend they use, in case that some other (yet unknown)
    backend needs the same workaround.

  • GTK sync-ui: workaround for “Sync Now” button not reacting to online
    status changed (BMC #9949).

  • Changed slow sync handling. Some users have complained about getting
    duplicated contacts (BMC #10081). The exact reason is not known (no
    useful logs provided yet), but it might be due to using “duplicate”
    as resolution strategy during slow syncs.

    This caused slightly different contacts to be duplicated instead of
    merging the two copies, reasoning that “no data loss” is better than
    “duplicates”. This release switches to a mode where the engine
    tries harder to avoid duplicates by merging data if modification
    time stamps are available for contacts (usually they are). When fields
    differ, the more recent data is kept.

  • convert absolute alarm back to relative (BMC #11233)

    Experiments show that at least Nokia phones (and thus perhaps also interpret a fixed alarm as “repeat alarm with the same
    relative offset as on first occurrence”. The same transformation to
    relative alarm times is applied whenever the transformation to
    absolute alarm is enabled for a peer.

  • Sony Ericsson: enable conversion to absolute alarm times (BMC #10092)

    Like Nokia and, Sony Ericsson phones also seem to be unable
    to deal with relative alarm times – verified with t700.

  • Sony Ericsson C510: workaround for SyncML violation

    The phone does not sent identifiers for the target database;
    using the source identifier as fallback allows a sync to

  • Fixed a regression affecting users who had created a config
    with SyncEvolution < 1.0. Using the config worked once, then
    failed with “No configuration for … found”. Users must
    manually remove the empty “peers” directory inside their
    affected configuration, the fix only makes configs without that
    directory usable again (BMC #9381).

  • Removed obsolete workaround for older mKCal calendar storage.

  • Fixed error message in QtContacts backend.
  • Same SYNCEVOLUTION_DEBUG code as in master branch.
  • Some updates to synccompare, including a workaround for a Perl
    bug seen on Debian Testing with Perl 5.10.1-16 (Perl panic).
  • Fix compilation of syncevo-dbus-server with libnotify 0.7.0 (BMC #10453).
  • Fixed compilation on Debian GNU/Hurd (no MAX_PATH, Mac OS X confusion).

Source, Installation, Further information

Source snapshots are in

i386, amd64 and lpia binaries for Debian-based distributions are available via the “stable” 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 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.

ScheduleWorld shut down – R.I.P

End of November, the service shut down. As a user
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
. 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
. For advanced users
the SyncEvolution server
might be
an alternative, but it is in a very rough state at this point and
requires a publicly accessible machine for anytime, anywhere