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.

Feature Implementation
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.
Protocols 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.
Supported GTK "sync-ui", command line
Community GTK applet "Genesis", Hildon-based GUI for Maemo 5
Supported Evolution, single item per file (works for KDE), sqlite (demo backend)
Community contributed and maintained by community: XMLRPC, Maemo 5/N900 calendar API
Other Apple Mac OS Addressbook (needs maintainer), iPhone (obsolete)
Core Features
Configuration 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).
Logging 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
D-Bus API 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.
WLAN 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
Contacts vCard 2.1 and 3.0, with extensions (spouse, manager, assistant, aniversary, gender, additional URLs, ....)
Events vCalendar 1.0 and iCalendar 2.0, including time zone support, recurrences, alarms, meetings
Tasks same as events
Memos plain text
Events+Tasks 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
Conversion 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 (feature request at
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).
D-Bus API covered by, using normal Python unittest module
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.