Therefore the main announcement of the 0.9 release went out via email and in the syncevolution.org blog. If you haven’t subscribed to that yet, then do so now because I’ll only write brief remarks about SyncEvolution development here – if I don’t forget about it because I am too busy with said development

Regarding this blog: I intend to keep it around to provide my personal opinions and updates, but announcements and information around SyncEvolution will be posted primarily via syncevolution.org. I’m not sure whether merging two feeds is possible with WordPress (any hints?) or Drupal (the engine behind syncevolution.org). So better subscribe to both feeds, lest you miss something important

For example, 0.9 beta 3 is available, with the full announcement here.

It includes my patches which add the new timestamping.txt user space API ( for hardware assisted time stamping of network packets. I also updated the igb driver for the Intel NIC 82576 and the user space PTPd, an implementation of IEEE 1588/Precision Time Protocol (PTP), so that finally there is a decent replacement for NTP in LANs and clusters. For details, see the LCI 2008 paper about that aspect.

This is my first Linux kernel patch. It would not have been possible without support by managers and colleagues at Intel and the patient code review by the Linux community, so kudos to everyone involved. Please contact the Intel Ethernet driver team if you have further questions about PTP or the Intel NIC 82576 features, I myself focus exclusively on SyncEvolution nowadays.

Unfortunately, PTPd is now officially unmaintained after a long period of no activity, so my patches for it were never looked at. Anyone interested in taking over the project?

It is not in the published schedule yet, but I’ll give a talk about the SyncEvolution project and our plans on Monday as part of the GUADEC track. While the project is currently mostly targeting Moblin+Evolution, it was always meant to be open for other contributions, so I hope non-GNOME developers will also attend the talk.

I also look forward to discussions about the architecture of our upcoming SyncML server and direct sync support. Now is the time to tell me how wrong I am with those ideas… before we implement them and find it out the hard way.

Since then we have added some minor fixes and improvements and later released the source as SyncEvolution 0.9 beta 2.

Changes

A GTK GUI! The “sync-ui” program depends on a backend D-Bus service (”synevo-dbus-server“) and several auxiliary files. Therefore it only runs without hacks after “sudo make install”, in contrast to the normal command line which can be invoked directly.

New configuration templates can be added to /etc/default/applications/syncevolution. These templates may contain icons which are used by the GUI (no icons shipped right now).

Information about previous synchronization sessions is now stored in a machine-readable format and can be accessed via the new --print-sessions options. The output of this information is more complete and more nicely formatted.

--status now not only shows data changes since the last sync, but also the item changes (see README for the difference between the two).

The new --restore option allows restoring local data to the state as it was before or after a sync. For this to work, “logdir” must be set (done by default for new configurations). The format of database dumps was changed to implement this feature: instead of in a flat file, items are now saved as individual files in a directory. To get the previous format back (for example, to import as one .vcf or .ics file manually) concatenate these files.

With --remove one can remove configurations. It leaves data files and the local databases untouched.

Various bug fixes and improvements:

• compiles and works again on Debian Etch if Boost 1.35 is installed from www.backports.org (without GUI, see Bugzilla #3358)
• uses XDG_CACHE_HOME (= ~/.cache) for logs and database dumps to avoid interfering with .desktop search in XDG_DATA_HOME; the directory there is automatically moved when running syncevolution (Bugzilla #3309)
• re-enabled certain config options (clientAuthType, maxMsgSize, maxObjSize); normally it shouldn’t be necessary to modify those (Bugzilla #3242, #2784)
• fixed error handling of unexpected server reply in libsoup transport (Bugzilla #3041)
• message logging is enabled at logLevel 3 (XML translation) and 4 (also original XML or WBXML message)
• GTK GUI fixes since initial Moblin 2.0 beta: only start it once if libunique is available (Bugzilla #3154), wrap text in change sync service” button (Bugzilla #2064), sort sources alphabetically in UI (Bugzilla #2070)

Next Steps

The goal right now is to work towards a stable 0.9 as quickly as possible. Primarily that involves interoperability testing with several different servers. The issue tracker contains a complete list of known issues that we would like to address. Some of them might have to be postponed, though.

Translation of the GTK GUI will be coordinated as part of the Moblin translation project, which will be open for external contributors. The Italian GNOME/Translation Project has already contributed a translation, many thanks! It has not been included in beta 2 only because we are still figuring out how the translation process will work.

Other contributions are also welcome. The Bugzilla contains a long list of ideas for enhancements: anything currently assigned to the team mail alias is fair game for anyone who wants to start hacking on something.

Not covered with specific work items is the implementation of a SyncML server mode in SyncEvolution. A design document for that is available, join the SyncEvolution mailing list if you are interested.

Source, Installation, Further information

See 0.9 beta 1: SyncEvolution 0.9 beta 1: Full-time Project, using Synthesis SyncML Engine
http://moblin.org/projects/syncevolution/
http://www.estamos.de/projects/SyncML/

I’ll stay away from work and email as much as possible during the next three weeks. It will be interesting to see what comes out of the recent SyncEvolution and Synthesis launch, but that has to wait. Our family upgrade is more important

This change is an opportunity for SyncEvolution to go beyond its traditional role of a simple SyncML client for Evolution. It’s too early to announce specific plans, but the intention is to include a GUI and also work on direct device-to-device and device-to-desktop synchronization. This will all be open source, so if you want to help, then let’s talk (see below).

Moving to Synthesis SyncML Engine

The other big change in direction is that SyncEvolution 0.9 will be based on the Synthesis SyncML Engine, which is getting re-released under the LGPL by Synthesis. The Funambol C++ library, the basis for SyncEvolution in previous releases, has served SyncEvolution well. SyncEvolution wouldn’t exist if Funambol hadn’t released their source code. I hope that my contributions to Funambol (port to Linux+autotools, interoperability testing, CPPUnit testing framework, to name just some of them) will continue to be useful even though now it is time to move on and I’m not going to contribute directly anymore.

I look forward to similarly productive cooperation with Synthesis. So far, I have added the autotools build scripts to it, made sure that it compiles cleanly with gcc on 32 and 64 bit, and fixed a few issues that came up due to the different way of using the source in SyncEvolution.

Why change a running system? It’s because the Synthesis code base is arguably a better match for SyncEvolution’s goals. The core engine is written in C++ and implements both the client *and* the server side of the synchronization. The Funambol server is implemented as a Java Enterprise application and depends on an application server like Tomcat. The bundle made available by Funambol of course runs on normal desktops, but this is not a replacement for a normal desktop application. Refactoring the server so that its SyncML engine can be used without an application server would be a lot of work and likely lead to patches that cannot be accepted upstream because they change the core architecture.

There are several other advantages that come from switching to the Synthesis engine:

• suspend/resume support (not used yet in 0.9 beta 1)
• description of SyncEvolution capabilities are generated automatically
• WBXML, the more efficient encoding of SyncML messages, is now supported (but disabled by default in 0.9 beta 1 for further testing)
• SyncEvolution can and will be licensed as LGPL, which is a better choice for a project that is meant to become the infrastructure that others build their applications upon.

Data Conversion

Because the Synthesis engine implements the data format conversions and merging required for a SyncML server and makes that functionality available also to SyncML clients, it was easy to implement another fundamental change in SyncEvolution: 0.9 switches from an “all items are sent verbatim to the SyncML server” to a “parse and convert” data handling model. The argument for the former approach was that the SyncML server should be the only entity in the system which does data conversion. But faced with real-world constraints, the previous releases already had to deviate from this approach to accommodate for minor client/server incompatibilities and for vCard 2.1 support.

The main reason for going to full semantic conversion is vCalendar 1.0 support. Support by servers for iCalendar 2.0, the only format supported by 0.8.1, is often still incomplete or even non-existent. By doing the conversion on the client side, SyncEvolution is now able to synchronize events and tasks with a wider variety of servers.

It is still true that properties not supported by a server cannot be synchronized to other devices, so using a server with full iCalendar 2.0 support is recommended. But in contrast to 0.8.1, information that can only be stored locally is no longer lost when receiving an incomplete update from the SyncML server thanks to intelligent merging provided by the Synthesis engine. This depends on an accurate description of the server’s capabilities, which might not be provided by all of them – still needs to be tested in more detail.

What do these changes mean for related projects?

I look forward to continuing the cooperation with Funambol and ScheduleWorld on interoperability. The use of open standards for synchronization is going to benefit everyone involved because it allows users to synchronize who wouldn’t be able to do that otherwise, but it requires testing to ensure that the different components in the system really work well together. Other SyncML server developers and operators are welcome to join the SyncEvolution interoperability testing as long as they:

• provide test accounts
• assist with analyzing problems
• support SyncEvolution users who want to use the service

With the goal of supporting direct synchronization, SyncEvolution enters a space that other projects also focus on, for example OpenSync and Conduit. We already discussed opportunities for cooperation with OpenSync: OpenSync currently doesn’t have stable code for conversion between different formats like vCalendar and iCalendar or vCard 2.1<->3.0, which is essential for a useful 0.40 release. Perhaps the Synthesis code can fill this gap. The Conduit project seems to be less focused on PIM data and mobile devices, but if there is a chance to cooperate, then it’s certainly worth discussing that.

The goal is to continue with SyncEvolution and Synthesis not just as open source, but also as open projects, with as much communication on public channels as possible. This is just getting started, so bear with us (and kindly remind us!) while we figure out how to do this properly.

SyncEvolution 0.9 beta 1

The focus of this first beta was to reach the same level of functionality and stability as in
0.8.1. Therefore this beta does not yet bring much new features; this
will be the focus of further beta releases until finally 0.9 will be a
full replacement for 0.8.1.

• vCalendar 1.0 is now supported. Because this hasn’t been tested that much yet, events and tasks are still disabled in most of the default configurations (SF #2635973).
• Both libcurl and libsoup can be selected at compile time as HTTP(S) transport mechanism.
• SF #2101015: Expect: 100-continue header results in 417 Error with proxy. Should no longer occur with the HTTP transports in this release.
• SF #1874805: Syncronization with Funambol results in loosing all-day property. This now works thanks to the Synthesis data conversion rules.
• SF #2586600: Synchronization with mobical.net fails. Should work now because of the different SyncML implementation (untested).
• SF #2542968: separator for categories should not be escaped. Done correctly by the Synthesis vcard conversion.

Known shortcomings in this release which will be fixed before the final 0.9:

• Verbatim file backups of items on the SyncML server are currently not possible: the SyncEvolution “file” backend still exists, but all items are converted by the Synthesis engine and therefore must be in a format supported by the engine.
• HTTPS can be used with libsoup, but certificate checking is always disabled. Need to find a portable way to determine where the certificate file is on various systems.
• Log file handling is not yet unified: the traditional client.log contains only high-level SyncEvolution log entries. Low-level SyncML and engine log entries are in sysync_*.html files.
• stdout and stderr messages from system libraries are visible on the console. 0.8.1 used to redirect those into the client.log to hide this noise; this will be added again. In the meantime, ignore messages like “Deadlock potential – avoiding evil bug!”. This is liborbit telling us that it is (hopefully successfully) handling something nasty.

Download + Installation

The source of SyncEvolution 0.9 beta 1 with the corresponding Synthesis source included is available here: http://www.estamos.de/download/syncevolution/sources/

Precompiled binaries will be made available for Moblin soon. For other platforms please compile from source. Compilation, installation and usage works as described in the README and on the upstream project site. Here’s how one can compile and use the latest sources:

cd /tmp
git clone git://git.moblin.org/syncevolution.git
cd syncevolution
./autogen.sh
mkdir compilation
cd compilation
../configure --disable-shared --with-synthesis-src=git://git.moblin.org/libsynthesis.git
make
PATH=`pwd`/src:$PATH
syncevolution


Further Information

Web sites:

• upstream SyncEvolution
• SyncEvolution, Moblin-specific aspects and development
• Synthesis Open Source

The following mailing lists are used for discussions:

• SyncEvolution, both users and developers
• SyncML related topics, both users and developers

The main bug tracker for SyncEvolution is on bugzilla.moblin.org (query open issues, report a problem or request an enhancement).

SyncML related issues can be filed there or directly on synthesis.ch.

The code is available in git repositories:

• SyncEvolution: git://git.moblin.org/syncevolution.git
• upstream Synthesis: git://www.synthesis.ch/libsynthesis.git
• staging area for patches against upstream Synthesis: git://git.moblin.org/libsynthesis.git

The goal of the libsynthesis repository on moblin.org is to prepare patches developed by the core SyncEvolution team and publish them for upstream inclusion. If you want to contribute patches yourself, then please work with the Synthesis repository and contact Synthesis regarding their contributor agreement.

The result is the following error:

GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Not running within active session)

A solution for Python is discussed on Stack Overflow. Here’s how the problem can be solved for SyncEvolution. In your crontab, use:

54 9 * * * env `dbus-launch` sh -c 'trap "kill $DBUS_SESSION_BUS_PID" EXIT; syncevolution'


This starts a D-Bus session (dbus-launch), runs syncevolution, then kills the D-Bus daemon (via the process ID set by dbus-launch) once syncevolution completes. It does that every day at 9:54. If you change that, then don’t run it too often, because that can consume a lot of resources on the server.

A while back I added support for synchronizing files in a specific directory. Each file must contain a complete item, like for example a VCALENDAR with a VEVENT inside. These instructions in the ScheduleWorld Wiki describe how SyncEvolution’s file backend can be hooked up with KDE4’s PIM.

There are some shortcomings, most notably KDE’s habit of copying instead of overwriting files when editing them. So I agree with Alex, this “less than perfect”, but it is better than nothing. The Akunambol code sniper project will provide direct access to KDE data and shouldn’t have this problem, but it remains to be seen when it will be finished. In the meantime, try out SyncEvolution…

• Compiler flags can be used to tune the executables specifically for the Atom CPU. The following gcc flags were recommended by Intel: -O3 -m[sse3 or ssse3] -march=Nocona -mfpmath=sse
• Enabling features which are off or not the default for normal desktop systems.

One drawback of the new architecture name is that the packaging tools refuse to install i386 packages. To overcome this I have added “lpia” to the architectures supported by the estamos.de APT repository. You can download 0.8.1 from there.

I’m not using any special flags or features because I don’t expect that they would make a relevant difference. In the future, the content will be exactly the same as for i386. For 0.8.1 I recompiled the same sources with the same settings.