Server with very good support for SyncEvolution, see http://www.memotoo.com/index.php?rub=infoSyncML. It is part of SyncEvolution’s nightly testing and included in the list of configuration templates that come with SyncEvolution.

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.

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.

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:

Google Calendar sync

Only supported indirectly through other SyncML services, like ScheduleWorld and GooSync, because Google itself does not provide access via SyncML.

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.

KDE is supported indirectly via the SyncEvolution file backend, which synchronizes items stored as single files inside a directory. That format is supported by KDE PIM. An old blog post contains some information and links about this. The SyncEvolution source code contains a “akonadi” branch with a database backend that talks directly to Akonadi, the PIM storage in KDE 4.x, but it needs a maintainer and more work to be usable. Perhaps a Google Summer of Code 2010 project will enhance it and SyncEvolution’s integration into KDE.

Known Issues

Evolution GUI

When importing or updating a contact from the server, some telephone numbers might only be displayed in the contact summary after editing the contact once. Evolution 2.0.4 till 2.6.3, ContactSync::testMerge test. Starting with SyncEvolution 0.4, this is solved by modifying the contact in the same way as the internal editor does. If it still fails, the server might send phone numbers without setting their type correctly.

End date of recurring events

Older versions of Evolution (like 2.0.4) use an Evolution-specific extension of iCalendar 2.0 to mark the end data of a recurring event. SyncEvolution makes no attempts to translate that into something that servers like eGroupware understand . This will not be added because this problem can be avoided by updating Evolution. Since at least version 2.6.3, Evolution uses the normal end date parameter.

Removing a recurrence not synchronized

The file backend of Evolution Data Server <= 2.27.5 does not increase the LAST-MODIFIED property of a recurring event when removing specific recurrences, therefore SyncEvolution does not recognize the event as modified and thus does not update the server. A fix for this is expected to be included in Evolution 2.28.

Adding timezone to Evolution

Evolution has a problem when SyncEvolution receives a calendar event with a new timezone definition. SyncEvolution adds the definition to the Evolution database, but an already running Evolution crashes, when trying to open the new event. Restarting Evolution solves that problem. The problem was found in Evolution 2.0.4, but has been resolved since.

Creating new address book

In Evolution, an address book has to be viewed once in Evolution after creating it (observed in 2.0.4). Otherwise, accessing it in SyncEvolution fails with:

gconf required

In an installation of Evolution, the libraries used by SyncEvolution crash unless the gconfd was started earlier, for instance, by logging into GNOME or running the Evolution GUI (observed with 2.4.2.1)