SyncEvolution core and Synthesis SyncML Engine#

This page lists core features available in SyncEvolution, focusing on the ones officially supported by the main developers in the binaries available on and in MeeGo. Features that might be expected, but are not supported, are also listed. The table starts with a general feature name and describes how SyncEvolution implements it, linking or pointing to further information whenever possible. Features introduced with a specific release of SyncEvolution or only available as described since a specific release are marked with that release number, like this: 0.9. For the sake of simplicity, only stable releases are considered. They might be mentioned already before the final release date.

This was page was written before the release of 1.2 and needs to be updated.



System Architecture

Frontends and engine separated by D-Bus API. Local data access provided by backend plugins loaded into engine. Compilation with everything in one process is possible.


SyncML (OMA-DS), 1.2: CalDAV/CardDAV working, ActiveSync planned

Sync daemon

1.0: “syncevo-dbus-server” owns configuration and runs/coordinates session among multiple frontends (like Netbook GTK GUI, command line, Genesis applet) which connect and disconnect dynamically. Implements automatic syncs without running frontend.



GTK “sync-ui”, command line


GTK applet “Genesis”, Hildon-based GUI for Maemo 5



Evolution, single item per file (works for KDE), sqlite (demo backend)


contributed and maintained by community: XMLRPC, Maemo 5/N900 calendar API


Apple Mac OS Addressbook (needs maintainer), iPhone (obsolete)

Core Features


Main SyncEvolution configuration via key/value style .ini files in XDG .config/syncevolution. Synthesis engine configured via XML, generated by SyncEvolution on-the-fly from its own config and XML fragments on disk (/usr/share/syncevolution/xml). Users can override those parts (.config/syncevolution-xml).


1.0: “syncevolution-log.html” file in session directories created in XDG .cache/syncevolution (“logdir” config property). SyncML messages dumped as XML translation at “loglevel=4” (not the default). Raw messages dumped at level 5. Session directories are expired automatically and intelligently to keep the total number below “maxlogdirs” (10 by default).

Automatic backups

Complete backend data is dumped into session directories before and after sync, to be restored in case of fatal sync errors.

Slow sync handling

1.0: slow syncs can lead to duplicated items or data loss, depending on the quality of the server. SyncEvolution clients automatically prevent unexpected slow syncs when this could happen (= local data exists), giving the user the chance to select the correct sync mode for the next sync.

Reporting data changes

0.9: statistics are collected during a client sync session. Not supported yet for server mode. “synccompare” command line tool formats changes in a diff-like format for power users (optional, see “printChanges” property).

Extension APIs


1.0: used by frontends. Full access to all features and configuration of SyncEvolution.

C++ Database backend API

Backends loaded dynamically. Can also be compiled statically into simple clients. API supports backends which import/export data in their own text format as well as backends which need items in some parsed format (Synthesis field list). Offers both “building blocks” to compose backends from existing parts (flexible) and a single-inheritance base class with pure virtual methods for the most common case (easier to use, see TrackingSyncSource).

C++ classes in libsyncevolution

Used by SyncEvolution internally. May change at any time, intended to be linked statically or with exact version dependency.

Synchronization “over the air” (= with servers on the Internet or company Intranet)

SyncML HTTP client

using in-process libsoup-gnome (MeeGo builds, automatically detects system proxy settings), libsoup or libcurl as transport libraries

SyncML HTTP server

1.0: syncevo-http-server, a Python script using the Twisted framework, accepts connections and hands them off to the syncevo-dbus-server for processing; designed as a single-user server

supported servers

ScheduleWorld, myFUNAMBOL, Synthesis, 0.9: Google Contacts, 0.9.1: Memotoo, Mobical, 1.0: (Vodafone)

other servers

used and tested by community: Oracle, Ovi, eGroupware, Horde, Goosync (access to Google Calendar)

Microsoft Exchange

planned for 1.2

1.2: Google Calendar

via CalDAV

1.2: Yahoo Calendar

via CalDAV

1.2: Yahoo Contacts

via CardDAV, disabled by default due to server-side issues

Direct synchronization (= mobile device to device or to desktop) via Bluetooth+OBEX or WLAN

SyncML server, OBEX client

Typically the “desktop” side of sync. 1.0: initiates Bluetooth connection via in-process libopenobex and sends SAN 1.0/1.1/1.2 supported (via “SyncMLVersion” property) to start a session

SyncML client, OBEX client

1.0: same as previous item, but sends a normal SyncML message to start a session

SyncML server, OBEX server

1.0: obexd accepts connection, hands over SyncML messages to syncevo-dbus-server

SyncML client, OBEX server

Typically the “handset” side of sync. 1.0: same as previous item, with SAN 1.2 being the supported format.


not supported, no standard defined, service discovery via DNS-SD under discussion between Intel and Synthesis

supported phones

1.0: no official list, infrastructure is (partially) tested with Nokia N900, Nokia 7210c (S40), Nokia N85, Sony Ericsson K750i

supported hosts

1.0: SyncEvolution itself, Nokia PC Suite and Apple iSync would be next step

Windows + Outlook

not supported directly, depends on Windows SyncML server like Nokia PC Suite

Data Handling


vCard 2.1 and 3.0, with extensions (spouse, manager, assistant, aniversary, gender, additional URLs, ….)


vCalendar 1.0 and iCalendar 2.0, including time zone support, recurrences, alarms, meetings


same as events


plain text


1.0: combination of events and tasks in one database as used by Nokia phones and, supported in SyncEvolution for both server and client via “type=virtual” (in SyncEvolution source config) and the Synthesis “super data store” which transparently combines two different databases


Done by Synthesis engine based on XML configuration, including translation between different dialects (X-SPOUSE vs. X-EVOLUITION-SPOUSE). Synthesis engine also offers scripting language for more advanced problems.

SyncML Features

SyncML versions

0.9: SyncML 1.0 till 1.2.2, see “SyncMLVersion” configuration property

Sync modes

slow, incremental two-way, incremental one-way from server or client, refresh from server or client; configured via “sync” property

XML message format

0.9: parsed and generated by libsmltk, the SyncML Toolkit library

WBXML message format

0.9: also handled by libsmltk, with the same API as for XML, no intermediate conversion to XML necessary => more efficient than conversion with libwbxml and using XML. Dumping messages as XML (for debugging) supported by Synthesis engine, see logging above.

Suspend&Resume, client

1.0: CTRL-C (command line tool) or D-Bus API (syncevo-dbus-server) triggers normal suspend (server is notified). CTRL-C twice in a row aborts the sync without allowing resume. No response from the server within “RetryDuration” time (config property) indicates a loss of network connectivity and also suspends the session, with the possibility to resume seamlessly without forcing a slow sync.

Suspend&Resume, server

1.0: Synthesis engine handles suspend request. SyncEvolution detects lack of further client messages after “RetryDuration” time and then suspends automatically.

HTTP message resend, client

1.0: messages without server reply are resent after “RetryInterval” time, to detect half-open TCP connections.

HTTP message resend, server

1.0: syncevo-http-server caches the last reply and sends it again when receiving a resent client message. Does not yet handle resends while a message is still being processed.

Automatic synchronization

At regular time intervals

1.0: implemented by syncevo-dbus-server, based on “autoSyncInterval” property. Must be permanently running for this. Normally it is activated on demand by clients.

Network access

1.0: automatic syncs only start if system is online long enough (“autoSyncDelay” property). Network access is never requested by syncevo-dbus-server itself.

Push sync

no support for sync requests from servers

Local change detection

no support for starting syncs after local data changes


Unit tests

CPPUnit embedded in C++ source code, executed by “client-test” only in developer builds

Integration tests

Again driven by CPPUnit/client-test, but uses public APIs and thus is available in MeeGo builds. Covers backend implementations (local tests, no server involved) and real client A<->server<->client B synchronization. Checks correct data handling in engine, backends and server, using “synccompare” tool to detect data loss. Simulates different sync scenarios (copying changes back and forth, large items, network disconnect, suspend&resume, message resend).

Nightly testing

Compile code on different Linux distros ranging from Ubuntu Hardy 8.04 LTS to Debian testing, both 32 and 64 bit. -Wall -Werror clean with g++ 4.3/4.4. Build binaries for download from Integration tests of these builds against supported servers and unit tests for test builds. valgrind is used for all test runs (still need to write suppressions for some false positives). Testing D-Bus API and syncevo-http-server is work in progress.