GSoC updates: the client agent

This follow-up post is about my proceedings for my GSoC project to integrate SyncML support in Akonadi. This consists basically of two parts, a server agent and a client agent. The former allows other devices to talk to your Akonadi server while the latter let’s your Akonadi server speak with others. Quite simple? Not really, SyncML is a complex and error-prone beast. That said, the server component might take some time to be ready, but the client agent is actually useful now. So let’s have a little test session!

The following stuff is pretty low-level, requires some compiler/shell knowledge, a KDE development environment set up and is not intended for end-users. Still there?

If you have your KDE development environment up and running, just checkout trunk/playground/pim/syncml from KDE SVN. You need to have libfunambol installed, which you can either compile for yourself from source our use a package from that repository (a patched libsyncml is available too, if you want to build the server agent). Not much to say here, just build and install it.

If you’ve reached this step you now should be able to add a SyncML client agent in the Akonadi resource configuration control module (system settings -> advanced tab -> akonadi configuration):


If you did so, you should now be presented with the following configuration dialog:


There you can setup the remote server (speak web-service) you want to sync with. Your job is basically to decide what parts of your PIM-data you want to be synced (contacts, calendar, etc.) and how to match the corresponding local Akonadi resource with the remote database on the server. Some more advanced values will be exposed soon, SyncML has gazillions of options available! Here are some possible values to toy with:

username/password: you should register!
contacts remote db: card
events remote db: event
tasks remote db: task
notes remote db: note

username/password: you should register!
contacts remote db: card
events remote db: cal
tasks remote db: task
notes remote db: note

username/password: you should register!
contacts remote db: con
events remote db: cal
tasks remote db: task
notes remote db: vnote

Rumors have it that some Google services are also SyncML-capable but I don’t know the settings needed. Feel free to post a comment if you know something here. As a sidenote, you can actually have multiple agents for several remote sides in parallel.

For now all that stuff lacks a GUI, there’s some initial work on a KControl module but for now we have to communicate via D-Bus with the client agent. The same is true for visual feedback. The agent is able to tell you whether the sync succeeded or not. If you want to know more, you have to watch Akonadi’s debug output for now. Fire up a terminal and enter the following stuff:

$ akonadictl restart
$ qdbus org.freedesktop.Akonadi.Agent.akonadi_syncmlclient_agent_0 / sync

Before you actually try this, be warned! This is unstable code that is still in heavy development and all kind of weird things may happen to your PIM data, so make a backup before you proceed.


GSoC status update for weeks 3-5

Ok, this one took a bit longer than expected. But better late than never..

In the last 3 weeks I’ve been concentrating on the SyncML server agent. Here is how it currently looks:

syncml server agent 1

As you can see, I streamlined it quite a bit but there’s still a lot of options available. This is necessary to cover all kinds of weird devices (and what they think what is standard SyncML behavior). Who ever told you that SyncML was simple is wrong 🙂

syncml server agent 2

One can already interact with the server, it should respond to simple queries but does no actual syncing with your Akonadi resources yet. More specific this involves to map Akonadi’s concept of resources and collections to libsyncml’s datastore concept. There’s usually one libsyncml datastore per content type available (one for notes, events, task, etc.) but Akonadi can have more than one resource for such things (For example my Akonadi instance has 3 calendar resources right now). This part turned out to be quite tricky, but I’m getting there.

A nice side-effect is that libsyncml now has one more project outside of the OpenSync project. We’re in good contact, I even got SVN access to speed up patching 😉 The bigger news is probably that libsyncml now has a stable branch.

That’s it for now, I’ll try to provide more frequent updates …

GSoC week 1-2 wrap up

Ok, time to write a bit about my progress in the first two GSoC coding weeks. So far, the foundations are laid out, I finally decided which SyncML implementation to use and how to realize what I plan. En plus, some code already hit playground 😉

First of all I decided to go for libsyncml as my backend. The two other competitors (Funambol C++ client SDK and libsynthesis) either don’t have all the required features (SyncML server mode, OBEX transport) or are difficult to handle from my POV. I did a rather lengthy review for myself and decided that this is the right way to go, even if libsyncml does have some issues here and there.

Before I’d like to go into further details, I’d like to revise what I’d like to achieve:

  • Being able to sync my mobile against Akonadi
  • Being able to let Akonadi sync against others
  • Configure all that in a comfortable way (don’t mess to much with SyncML)
  • Have it automated (where possible)

Being able to allow a mobile device to sync with my desktop’s Akonadi instance effectively means running a SyncML server to which the device can connect to and which interfaces with Akonadi itself.

Therefore we need a “Akonadi SyncML server agent”:


And the corresponding configuration interface:


There you can set how you want to expose SyncML functionality and what resources you want to be sync-able. Some advanced SyncML stuff is also there to help with all the beasty devices out there (more than you might think). As you can see, right know only one server instance is allowed to run at the same time, but this might change in the near future. For example you might want to have one OBEX / TCP server which exposes all your contact resources for your mobile and another one via HTTP which exposes each and every resource available for another Akonadi instance (I’ll come to that in a moment). Even more so, you might want to set some proper SSL encryption your HTTP setup but not necessarily for the mobile device (we’re all lazy aren’t we?).

Depending on what you are up to you might want to let your Akonadi instance behave like a client, e.g. let it go knocking on some web services (, ScheduleWorld, Google stuff, etc.) or another Akonadi instance. And you don’t want to do that by yourself all the time. So we need a “Akonadi SyncML client agent” to do exactly that. Here’s the config screen draft:



This is where you can set how to access the remote server and again, what Akonadi resources you want to have synced. You also have to set some SyncML-specifica to access calendars and contacts on the remote partner. As you can see here, SyncML clients should be able do their job in different ways. You might want to have one client which syncs weekly with your google calender and you might want to have one client on your laptop which syncs with your desktop’s Akonadi instance upon network discovery (help, please!!).

And to be able to configure all that stuff without getting lost, we’ll need a KCM module. A profile concept remains to be elaborated to hide away all the complexity (more in a follow-up post).

Some code can already be found under playground/pim/syncml but you need a pretty recent version of libsyncml and libwbxml to get this to work. You can also fetch those dependencies with some patches applied from my SUSE-BuildService repository for several RPM-based distros: