Compatibility

Since 0.6, SyncEvolution runs not only with Evolution, but also with the Evolution backend, as used in the Nokia 770/N800. When the N810 became available, 0.7 was also compiled for it. In 0.7, support for the Mac OS X and iPhone address book was added. When compiled for that, the resulting SyncML client works without any Evolution libraries. Other data sources could be added the same way. This page describes the available precompiled packages and what they are compatible with.

Because SyncEvolution only communicates with SyncML servers, the primary concern is whether this data exchange works, along with how SyncEvolution and the server must be configured to get data exchange to work. How the data is then sent to other devices is also important, but this is mostly out of SyncEvolution's control. Therefore, this page focuses on servers and copying from one instance of Evolution to another, but not so much on copying between Evolution and specific devices.

Of the servers listed here, SyncEvolution is regularly tested with ScheduleWorld, Funambol, Google and Synthesis server, so, the information about known problems with them is also more detailed. Not listing problems with other servers does not mean they do not exist... If you have tested with a server not listed here or would like to add further information, then your updates to this page, sent to email, are highly appreciated.

If you would like to have SyncEvolution tested regularly with a specific server, then you need to provide the following:

• a description how to configure SyncEvolution for this server
• an account on the server for the nightly testing
• help with analyzing any errors that might come up during testing

Supported Platforms

Evolution

The source of SyncEvolution should be compatible with any Evolution release since 2.0. The packages prepared for regular releases >= 0.9 are compiled on a Ubuntu Hardy 8.04 LTS system (32 and 64 bit x86), and tested with different versions of Evolution. The binaries should run on all distributions that are more recent than Ubuntu Hardy and have a compatible Evolution.

Windows

In theory, the source code for Evolution could also be compiled on Windows, but so far no one has tried it.

Nokia 770/N800/N810

The 0.8 .deb package is compiled for the first ITOS 2008 release, so it no longer runs on ITOS 2007 or older. It is tested with a Nokia 810. Synchronizing the system address book is the only tested function, although calendar synchronization also works with the Dates application.

The program is a direct port of the desktop version, that is, there is no GUI. One can either log into the device through ssh or install osso-xterm to invoke the syncevolution binary.

If the number of contacts is high (such as a few hundred), then extracting all of them will take awhile (several minutes). Because, normally, they are all stored in backup files before and after each synchronization, that alone slows down each synchronization considerably. This is normal. The only way to speed it up is to use "logdir = none".

Mac OS X and iPhone

Note: Only contact synchronization is supported. See this blog post about calendar support.

Contacts are exchanged as vCard 2.1. Some aspects of contacts cannot be synchronized because of limitations of that standard (lost when sending out contacts), of the iPhone/Mac OS X address book (lost when receiving contacts) or of SyncEvolution itself (lost during conversion):

• custom email/address/phone labels are sent, but might not be handled by a SyncML server
• multiple email/address/phone entries with the same label are supported, but SyncML servers might only store one of each kind
• the order of email/address/phone entries might be changed by a server because the explicit ordering of the address book GUI cannot be stored in the vCard
• PO box and extended address information are not supported by the address book
• iPhone: a name prefix (like "sir") is not supported, only a job title is available in the address book
• chat contact information is not supported by the address book on the iPhone. On the Mac OS X, only AIM/JABBER/MSN/YAHOO/ICQ contact information is synchronized using extensions which might not be supported by a SyncML server
• related names are not supported by address book on iPhone. On Mac OS X, only manager, spouse, and assistant are synchronized with the same vCard extensions also used by Evolution (X-EVOLUTION-MANAGER/ASSISTANT/SPOUSE), which might not be supported by a SyncML server
• only company and department are supported by the address book. Additional levels in a organization are lost
• maiden name, additional dates, and additional flags per contact, as supported by the Mac OS X address book, cannot be represented in the vCard standard and are not synchronized
• calendar and free/busy URL as supported by the vCard 3.0 standard cannot be stored in the address book
• address book contact groups could be mapped to vCard categories and vice versa, but this is not currently implemented

There are also some known problems and areas for improvement:

• resolving the name of the server can fail, even though the Safari browser can resolve it, then after that syncevolution can also resolve the address. Since November 27th 2007, ScheduleWorld moved sync.scheduleworld.com off of a CNAME and onto a dedicated A record to avoid this problem

Compatible SyncML Servers

ScheduleWorld

It is recommended to sync against ScheduleWorld using its new vCard 3.0 URI (card3), iCalendar 2.0 URIs (cal2, task2), and text memo URI (note), with the "text/vcard", "text/calendar", "text/x-todo", and "text/plain" type setting, respectively. These are the native formats of Evolution and a lot of effort went into ensuring that they store as much Evolution data as possible. The "scheduleworld" example configuration is ready to be used with these URIs, one only has to fill in the real username and password.

ScheduleWorld preserves almost all Evolution contact and calendar data. The exceptions are:

• recurring events relative to UTC are transformed to events relative to the user's time zone, as configured in his settings
• the schema used to store contacts does not distinguish between different emails, so although all email addresses are preserved, their type gets lost

Google contact sync (only with SyncEvolution >= 0.9)

Google follows the vCard 2.1 specification, and thus does not support some of the vCard 3.0 additions, nor some of the common extensions. As a result, several properties are not synchronized (nickname, birthday, spouse/manager, URLs, ...). Only one top-level organization seems to be supported. For details, see README.google.

Regarding Google's SyncML support, refresh-from-client and one-way-from-client sync modes are not supported. Deleting contacts moves them out of the main address without deleting them permanently. When adding such a contact again, the server discards the data sent by the client and recreates the contact with the data that it remembered.

Because SSL certificate checking for Google works only with libsoup if the platform has a patched libsoup (http://bugzilla.gnome.org/show_bug.cgi?id=589323) or libsoup >= 2.28, certificate checking remains turned off by default for Google. If your platform has a suitable libsoup (like Moblin 2.0), then enable checking with:

Funambol

Since SyncEvolution 0.9 with calendar and task support. Funambol supports iCalendar 2.0 in the current server, so this is enabled in the configuration template. Not all iCalendar 2.0 features are supported by the server, most notably support for meetings (drops attendees), meeting invitations (drops UID), detached recurrences (drops RECURRENCE-ID). See README.funambol for details.

Interoperability with the Funambol server was improved in SyncEvolution 0.9 by adding support for some vCard extensions (X-MANAGER/ASSISTANT/SPOUSE/ANNIVERSARY, #2418). Lost ACTION property has a work around (#2422).

To enable the full support for all data in a configuration created with SyncEvolution < 0.9, so that it exchanges items in the more suitable iCalendar 2.0 format, use:

Without the exclamation mark, format auto-negotiation would pick the less capable vCalendar 1.0 format because that is marked as preferred by the server.

OVI.com

OVI.com is Nokia's set of web services, including among them complete PIM data handling and synchronization with phones via SyncML. Formal interoperability testing has not been done yet, but a user of SyncEvolution 0.9.1 reports that it works for him. Getting the necessary setting information for SyncEvolution is a bit tricky, so check out his nice report for a step-by-step guide.

Synthesis

The Synthesis server is a very configurable server which stores its data in a database. Contact data can be exchanged in vCard 2.1 and 3.0 format when using the default configuration, but due to how it is stored, several attributes used by Evolution get lost or modified. It might be possible to protect against loss of those attributes, by tuning the Synthesis server setup. More work would also be required to exchange calendar entries and tasks, because in the default configuration they are not accepted in the iCalendar 2.0 format of Evolution.

Horde

Contributed on 08.05.2006 by Todd Pytel based on an early 0.4 CVS snapshot.

The Horde framework includes a SyncML component compatible with SyncEvolution and other SyncML clients. This component is built in to the core framework and does not need to be separately installed. For synchronization to work, you need to do a few things....

1. Use fresh Horde sources: Many SyncML changes are applied only to Horde's CVS HEAD branch. The stable branch does include some SyncML support, but it's not as complete as what's found in CVS HEAD. If you really don't want to use CVS HEAD sources entirely, you might be able to get away with updating just the files /horde/rpc.php and /horde/turba/lib/api.php. Try the versions from the stable CVS branch first before trying HEAD, and don't complain if they don't work correctly on top of a release installation. Much better to just use CVS HEAD altogether.
2. Configure authentication: On the Horde server, the only thing that might require configuration is authentication. By default, SyncEvolution will use md5 authentication, which is nice when you're using HTTP rather than HTTPS. Support for md5 was very recently added to Horde, and will almost certainly have changed by the time you read this. At the moment, see the comments in SyncML/Backend.php around line 404 for details. Alternatively (and more easily), run SyncML over HTTPS and tell SyncEvolution to use basic, non-md5 authentication, by adding
   clientAuthType = syncml:auth-basic serverAuthType = syncml:auth-basic

   to the ~/.sync4j/evolution/horde/spds/syncml/config.txt file (see below).

3. Configure SyncEvolution: Read the generic SyncEvolution docs, then come back here. Copy one of the prepackaged configuration directories (like etc/scheduleworld_1) to ~/.sync4j/evolution/horde as a starting point. It doesn't matter much which template directory you use. They're not very different, and there's not much to configure. You need to modify (or create) the following items. In ~/.sync4j/evolution/horde/spds/syncml/config.txt:
   syncURL = https://your.horde.site.com/horde/rpc.php

   Adjust http/https appropriately and make sure the address matches the webroot configuration on the server.

   deviceId = sc-api-nat-<identifier>

   Each computer/username combo that syncs should have a different identifier, for example, using an identifier like "home-myusername" makes sense. The username and password lines should match your Horde username and password. Add the AuthType lines from #2, if you don't want md5 authentication. Next, decide which Evolution databases you want to synchronize. I use only the addressbook, but the others should be similar. In ~/.sync4j/evolution/horde/spds/sources/addressbook_1/config.txt set

   uri = contacts

   That's it. The other components use "calendar" (Kronolith), "notes" (Mnemo), and "tasks" (Nag). If you don't want to synchronize a particular database, be sure to set "sync = none" in its config file.

4. Try it out:
   syncevolution horde

   If you get errors, check out the Horde Sync wiki for more information on debugging. The sync@lists.horde.org mailing list is also very useful. Check the archives there, to see if there's any info about your problem.

Enhancement (Note: This may be unnecessary when Turba 3 is released.)

The default configuration for Turba (Horde's address book component) is less than ideal for SyncML, because the turba_objects database table is somewhat oversimplified (for example, all components of an address are combined in a single field). This leads to vcards that are missing some fields when they're synced between Horde and Evolution. Fortunately, Turba is very clever, when it comes to reading its database, and can automagically adjust to many nondefault configurations. If you're creating a fresh Turba installation, you can improve its SyncML capabilities greatly by using this custom sources.php file. If you do this, then you'll also need to make sure the appropriate fields are available in the turba_objects table in your database. Using this postgres script, instead of the one included with Horde, will create an appropriate turba_objects from scratch. For MySQL, there is no such script available, so make the changes manually. Nothing else needs to be done with Turba, apart from using the custom sources.php and creating an appropriate turba_objects table. The Turba code will automatically recognize the new fields and use them correctly in SyncML transactions. Thanks to Karsten Fourmont for providing this solution.

eGroupware

Contributed on 10.09.2006 by Mathias Weyland, who also graciously provided access to a server for testing. Thanks!

SyncEvolution can handle synchronization with eGroupware (eGW), starting with 0.4-pre2 plus one patch, which was included in 0.4.

Make sure eGW fits the needs for correct operation with syncML, in particular php5 and Pear::Log. See here for information about requirements and settings.

The SyncEvolution setup is rather straightforward. Although the SyncML code of eGW is based on horde (see above), there's no need to restrict authentication to auth-basic.

Set syncURL to http://<host>/<egw-base>/rpc.php. Set "type = text/calendar" and "uri = ./calendar" for the calendar and "type = text/x-vcard" and "uri = ./contacts", respectively for the address book.

Warning: "uri = ./calendar" apparently is the official uri, but several users reported that with that setting events created in eGW were not copied into Evolution while "uri = calendar" worked alright. Until this is clarified, the recommendation is to use "uri = calendar".

All in all, synchronization is working well, but I'd like to mention some things I noticed not to work:

• Recurring events don't stop at a final date in eGW, even when this final date has been set in evolution.

  "A known issue of old Evolution versions." -- Patrick

• Recurrence exceptions are not respected.

  "eGW seems to rely on storing the remaining instances of an event, but does not include this information in the data it sends to SyncEvolution. On the other hand, SyncEvolution also does not yet support this either. Exceptions defined in Evolution's dialog are stored as simple properties and are sent to the server, but eGW does not seem to use that information."

• New appointments in eGW are not sync'ed to evolutions. But updates are.

  "Could not reproduce. If it still occurs, please submit a bug report."

• With SyncEvolution 0.6, Ioannis Ioannou had a problem with lost or messed up telephones. Part of the problem was in SyncEvolution (it did not correctly detect types as sent by eGW, fixed in 0.7), part of the problem was in eGW (it does not handle the vCards sent by SyncEvolution correctly). Ioannis found out that eGW has hard-coded mappings for incoming data, which might have to be adapted on a case-by-case basis for clients. He submitted a patch (thanks!) which adds a SyncEvolution mapping to eGW. Hopefully this problem will be fixed. The original version of his patch changes class.vcaladdressbook.inc.php in egroupware/addressbook/inc and was tested on 1.4.001, 1.4.002, and the trunk of 2007-09-25th.
• If communication with eGW stops with a Server Failure: server returned error code -1 error, then the reason is most likely a parser problem in eGW. Some information about this can also be found in the same discussion thread.

Other Servers

Here are some more servers that one could synchronize against. None of them have been tested yet with SyncEvolution, though:

• MightyPhone
• S-Sync