Last weekend various OpenSync and KDE developer meet in Berlin, in the KDAB office. As usual, lots of discussion and nearly no sleep.
Cornelius Schumacher actually came up with the idea to have such a meeting, to finally bring OpenSync back to speed. So few weeks later we ended up in Berlin finally meeting some of the OpenSync- and KDE developers in person. The bottom line of the meeting in one sentence: Highly productive and helpful!
We shared lots of information, experience, contacts and ideas. Especially having Volker Krause and Tobias König at the table, which bring together 12 (person)years (2person * 6years = 12 personyears) of PIM experience on the table was really helpful. Since we constantly get in touch with PIM issues, especially Christopher Stender, who takes care about the OpenSync vformat plugin, which handles vCard 2.1/3.0, vCalendar and iCalendar.
There was also time to do some hacking (usually until 2am/3am):
- Michael Bell fixed libsyncml for all participants SyncML-capable mobiles. Also diagnosed various issues on the mobiles itself.
- Volker Krause started writing akonadi-sync!
- Christopher Stender and Björn Ricks reviewed some dark-areas of the OpenSync Core component: conversion path code (it's about finding the shortest conversion "path" from format A to B by having no direct format conversion functions between A and B, but utilizing format X, Y and Z to get to format b)
- Felix Möller took care about the big lack of proper documentation of our reference implementations and did, like he always do, bug screening of approx. 200 open tickets.
- Tobias König started after some discussion port KitchenSync to latest OpenSync API. This included to get rid of the random-XML-plugin-configuration parsing, which i guess was up to 50% of the codebase of KitchenSync, and replacing it by the new OSyncPluginConfig API. The purpose of the OSyncPluginConfig API is to make the life of Tobias and other OpenSync Frontend/UIs authors easier and allow to write some generic code which works with all OpenSync plugins. Before this OSyncPluginConfig API got introduced all OpenSync frontends had to write individual configuration parses/assembler for each plugin - since every plugin was allowed to have their own random configuration (unfortunately also very undocumented). Also John Carr from Conduit stated this as a PIA to do any OpenSync integration in Conduit.
We had also lots of lighting talks/presentations about various topics:
... by Volker Krause. Akonadi looks really promising. I hope to see Akonadi turns into a freedesktop.org project and gets widely used. So there is some common PIM interface - especially in the days where are several Open Source mobile platforms are present (Maemo, OpenMoko, Qtopia, ...) and some of them still lack some PIM Sync interface. With libsyncml there would be a nice SyncML protocol implementation which even support OBEX as transport ... the only difficulty for us to deploy SyncML on such interface is actually that we're not familiar with all those individuals PIM Storage APIs. What about Akonadi on such devices? Having one central PIM Storage we could join forces and implement complex stuff like "Rollback" on the PIM Storage when the synchronization gets aborted. Michael mentioned this kind of feature is unfortunately really rare on SyncML implementations. Also the experience from 10 years of KDEPIM is for sure a big PLUS to use Akonadi. Is your PIM still performing well with 4000+ contacts? I bet Akonadi is!
OpenSync - Brief Overview
I gave a quick overview about the OpenSync project and stepped through the synchronization process to show how OpenSync tries to avoid duplicates and data loss syncing all kinds of data. Followed by a very productive discussion how we might solve outstanding issues which a very common on PIM how to handle different limits of max occurs of Addresses, Telephone numbers, ... in contacts between different application/devices.
OpenSync - Plugin HowToPretty nice introduction how to write an OpenSync Plugin by Michael Bell. Since i'm mostly having the view from Framework on plugin it was really interesting for me how Michael summarized how to write a Plugin. This is a mandatory reading when writing a OpenSync plugin!
OpenSync Plugin HowTo Slides
Bertjan Broeksema gave us a overview whats going on with KPilot. This was very interesting to me, since i used to have the palm synchronization tools as the perfect example why we need to have something like OpenSync. Bertjan cleaned up KPilot and refactored all synchronization logics down to one single synchronization logic in KPilot. So we might have a look once KDE 4.2 got released to the actual synchronization in KPilot via KitchenSync. The idea is to make KitchenSync only partial visible, only when some conflict resolution by the user is required. So it's completely transparent to the KPilot user that KitchenSync/OpenSync got used... for other task KPilot will be still up to KPilot.
libsyncml - Theory & Praxis
Michael gave a brief overview about libsyncml chopped in two presentations: Theory and Praxis. The theory part covered libsyncml features, the new High Level API of libsyncml, libsyncml roadmap, Brief HowTo to deploy our version of a SyncML stack and how a deployment of libsyncml might look like on a mobile. The 2nd part, Praxis, overview about the libsyncml test automation, the new libsyncml reference implementation syncml-ds-tool, the OpenSync SyncML plugin and some status overview how well libsyncml is doing with other SyncML on various mobiles and SyncML servers. My personal summary on libsyncml: Since Michael started hacking libsyncml we have the feature-richest (we support OBEX! ;)) and one the most rock-solid SyncML stack of all!
Postmortem of 0.30 development cycle
We identify several mistake which were made during the 0.30 development cycle. The barrier on contributing/joining the project is quite big. Due to lots of API redesign the constant breaking of the API made it really hard to keep up with the development. At the same time not doing frequently releases gave the impression for people outside of the development (those who not reading SVN commits ;)) that the project was stopped. We also didn't spent lots of time in advertising project. This is also one of the reason why i started (again) blogging... (no I'm not bored, but not taking care of the right balance of PR and development seems to made OpenSync quite unattractive). Regarding breaking the API, we don't plan to continue this once 0.40 is out ;)
Future of Syncing on the Desktop
It seems to be that the PIM folks share the same problem like OpenSync projects does. There are to many people working on the same problems without proper communication and sharing a common codebase. Akonadi is trying to get a freedesktop.org project - but this process seems to be stuck. This really sad! Unfortunately Halton Huo (author of gnome-sync-tool) and John Carr (Conduit developer) couldn't make it to this meeting due to various reasons. First it looked very promising to have them on the table, so this would be the first time we would have OpenSync UIs developers also from KDE and GNOME on the table. Especially i would have been interested in what is going on with the OpenSync integration in Conduit? Is it just about "hijacking" the plugins and not using the Synchronization logic or are there plans to actually use the OpenSync Framework including the Synchronization Engine? Speaking about joining forces and sharing common code base - recently Sascha Peilicke from Trolltech announced on one of the OpenSync mailinglist that he's going to start (or already started?) writing some PIM Sync application based on Funambol C++ Client API. At this time I heard the first time that there is a Funambol C++ Client API ... it's Open Source! So thats fine with me - something which worried my was that he stated that he decided to NOT choose libsyncml as SyncML because of: "Glibc and
libxml have a footprint around 2.5MB (correct me, but i tested it) without
your app." - i guess "Glibc" was a typo and he meant "glib" - but thats really annoying. Ok, libxml might be the biggest dependency (there is a parser/assembler abstraction in libsyncml, so it's easy to replace it by a non-libxml implementation - if someone want to volunteer - I'm more then happy to pickup a patch like this) - the thing which is really annonying me, in case he meant "glib" - i doubt Qtopia is to 100% free of glib - maybe it's just statically linked? This Glib vs. Qt stories are really annoying... Bottom line: We need to bring all PIM and Sync heads on the same (physical) table! To keep up with non-Open Source solution we have to join forces, communicate together and concentrate on common code base for logical-, protocol-, format-specific implementation. If you're interested in such cross-platform-free-desktop PIM&Sync meeting feel free to contact me!
More details about the Meeting
Thanks to KDAB for offering the office and KDE e.V. to sponsoring this hacking session!