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 syncevolution.org 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.
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. |
Frontends |
|
Supported |
GTK “sync-ui”, command line |
Community |
GTK applet “Genesis”, Hildon-based GUI for Maemo 5 |
Backends* |
|
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 ( |
Logging |
1.0: “syncevolution-log.html” file in session directories created in XDG |
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: ZYB.com (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 Ovi.com, 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. |
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 |
Testing |
|
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. |