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 (myFunambol.com, 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: