[Kde-pim] SyncML meeting - conclusions

Fri Jun 4 11:52:49 BST 2010

On Friday 04 June 2010 11:11:24 you wrote:
> Hi,
> since the meeting has been quite messy for various reasons, I offered to
> provide a little summary for everyone on how things went.
> 
> After some discussion on the frameworks and on the various possibilities we
> had, we reached some kind of consensus on the following proposal, done by
> me. I report it here for further (eventual) discussion.

Uhm, at least a consensus with some actors missing. This proposal (done by 
you) makes me feel like being stabbed in the back literally, that 'consensus' 
must have happened after I quit the meeting. But let's have a look at things 
one after another. This mail is intended to express that there is no such 
consensus and maybe I should excuse in advance to the list as this response 
was written with a bit of a temper. Actually I'm not in the mood of starting a 
flamewar but not responding to this mail could lead to a lot of question marks 
regarding the current state of SyncML for KDE. 

I'll try to sum up the current situation for all those that don't follow that 
topic to closely. Currently there are several attempts on getting SyncML 
support for Akonadi. One of those was a GSoC project done by me based on a 
successful experience with Qtopia. The outcome of the project was a near-
working solution which is not stable enough to be reliably used.

> The plan:
> 
> - Akunambol
> The plan would be to use Akunambol as main KDE syncing solution. What it
> would provide is user interaction, an interface, an autosyncer and stuff
> like that. It will also provide an abstract interface to load backends
> (syncevo or funambol, or eventually more in the future) ala phonon. We
> already asked Dario Freddi for some insight on this and he says that,
> given our requirements, it's easily feasible.
Those plans for Akunambol are all nice and neat and I support those. 
Nonetheless is currently not anywhere near being 'the main KDE syncing 
solution'. As I said towards the end of the meeting, such a plugin mechanism 
may be hard if not impossible to realize as the feature sets of both backends 
differ a lot. Such plugins would have to provide these feature sets and your 
front end app (Akunambol) would have to enable/disable large parts of the UI 
code. And it may not even make sense as all SyncEvo is a superset of Funambol, 
where the former (AFAIK) still provides an API that is similar to the latter. 
It is understandable that you don't want to scrap your baby to go for a 
different (but superior) solution. I've had a look at the current code base 
again and besides that it is failing to build (with recent funambol packages), 
that gui is currently little more than a 'sync now' button. And it is only 
contacts by now. Nonetheless I'm all for developing it further but don't try 
to over-advertise it. Besides there are other already successful 'KDE sync 
solutions' like KPilot.

> - Funambol
> This is the backend that we have already ready, and which works well. It is
> not capable to directly sync a phone via bluetooth but is quite solid for
> standard web usage. It will be, at least at the beginning, the default
> backend which will ship with akunambol.
My impression is that somehow repeating all the issues we faced (and the 
reason for which SyncEvolution exists after all) are ignored again and again. 
This includes all the talks and mails that where kindly provided by Patrick 
Ohly, our local SyncML-guru, as well as the experiences i've got (which 
includes a working solution for Qtopia). Anyways I'm tired of repeating 
myself.

> - GSoC and SyncEvolution
> Dinesh agreed that he will continue working on the SyncEvolution backend.
> Since he is just getting familiar with the code, we agreed that instead of
> replicating things and starting a new interface, he would just code an
> Akunambol backend, which can be shipped with akunambol when it's ready, and
> that the users can choose and load at runtime.
That's not yours to decide and at the same time crap. There won't be such 
thing as an Akunambol backend. There will be a SyncEvo Akonadi backend as 
stated in the GSoC proposal. There's no such thing as 'replecating 
interfaces', there's a (mostly) well-defined mechanism to create new backends 
for SyncEvo, that what he's going to utilize. Patrick already promised to help 
on those little issues that happened to both Ravi and Dinesh. Maybe I should 
clarify things, I am the GSoC  mentor of Dinesh and the Seasons of KDE mentor 
for Ravi, so as far as I'm in those roles I want to be informed about such 
decisions. 

> Me, Sandro Munda(?) and Micheal Zanetti will continue working on akunambol,
> leaving the rest of the guys able to concentrate on syncevolution and KDE
> integration.
That's the most sensible idea so far and I support that. This implies that 
everything will stay as it was before that ill-fated 'meeting'. Dinesh will 
continue to concentrate on his GSoC, which actually just started, and you guys 
can work on Akunambol. I for myself started an initial KDE frontend for 
SyncEvo which I intend to put into Ravi's hands. That will be based on 
SyncEvo's D-Bus interface alone and will reuse some stuff I had already for 
user and config profiles. Whatever turns out to be the most feasible solution, 
that may become 'the main KDE sync solution' maybe. Or maybe it's several 
solutions with different scopes, how knows.
-- 
Kind regards,
Sascha Peilicke
http://saschpe.wordpress.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100604/a6157e16/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/