[Kde-pim] GSoC: Akonadi SyncML support

[Riccardo Iaconelli]

On Saturday 10 April 2010 13:56:11 Patrick Ohly wrote:
> Hi Riccardo!
> 
> It's good to see that you got something out. Congratulations!

Thanks, it's a very nice feeling indeed. :)
 
> On Fr, 2010-04-09 at 20:35 +0200, Riccardo Iaconelli wrote:
> > Now, since I don't really feel like trashing, just after the first
> > release, all the code and all the effort that I put into it, and since
> > it is already there and it already works well, until I finish
> > implementing the needed features I'd like to continue developing it as a
> > very lightweight application that, in a very UNIXey philosophy, does one
> > thing and does it well,
> 
> Syncing with an HTTP server and a phone are very similar. Some extra
> work is needed to simplify the setup of direct sync with a phone, but
> the rest of the GUI is identical. Therefore I don't think it makes sense
> to focus on just one use case when there is an opportunity to get both.

Well, sure, the basilar "sync contacts", "sync calendar" and "sync all" will 
stay there, but i'm assuming you would have for example to find your phone via 
bluetooth and do some kind of pairing. Not too difficult, but in percentage, 
it's much more UI. :-)

> > eventually
> > with room for additional features and integration.
> 
> One of the problems you have right now is that the sync engine runs
> inside the same thread as the GUI. As mentioned in the response to your
> 0.1 announcement, that causes the GUI to lock up noticeably while the
> engine is busy. Changing that is not just a matter of adding something,
> it is a key design decision.

 
> As you might know, SyncEvolution solves that by separating frontend and
> backend. The actual sync runs inside a D-Bus service daemon, which is
> also necessary to implement features like automatic sync without running
> the frontend.

I was thinking of simply putting everything into a kded daemon, when I have to 
implement automatic always-on syncronization.
 
> > But I'm also definitely open to thoughts on what to do for the future. :)
> > After all, I think that joining forces is much Better(tm) than
> > reinventing the wheel. Anyways, just throwing some ideas here: what if
> > we made the target of the GSoc to develop a "backend" for akunambol, so
> > that, when it finds SyncEvolution over dbus, it is able to use some of
> > its features? That would still an Akonadi plugin for syncevo, but it
> > would mean reusing the UI and allowing deploying additional features in
> > an easier and more granular way on a working and tested utility. Or, I
> > don't know...
> 
> Conceptually the configuration of SyncEvolution and Funambol are
> similar, so that part might work. But progress events during a sync are
> very different. I also don't know how manageable the GUI code will be
> when it has to implement everything twice: once for Funambol as embedded
> engine, once for SyncEvolution over D-Bus.

Well, the UI is already quite abstract in regards to what underlying sync 
mechanism it is using (also because for historic reasons, I had to first 
"develop" it as an empty shelf on top of no actual functionality).

I have a "source manager" which gets signals from the UI, handles asking 
Akonadi about the collections of contacts, makes sure that everything is OK 
and prepares the syncsource, to finally call a sync() signal when it's ready. 
It needs to be abstracted (and reorganized) a little more since for now it 
assumes we only want to do contacts, and I'm pretty sure that I can use some 
refactoring to make the code more elegant, but I really don't think that 
handling two sources is too much of a problem.

So this point from the GSoC would be mostly done already:
- 1) A qt based replacement for gtk sync-UI. At least the Qt/D-Bus hints in 
the D-Bus .xml files can and should be shared.

> > Oh, by the way, how does SyncEvolution work on embedded devices?
> 
> I expect it to work well, but haven't tried anything myself. The
> Synthesis engine is used in mobile devices and SyncEvolution doesn't add
> much overhead to that.
> 
> Do you have a specific device in mind?

Not one specific, but I am thinking of a possible integration of Akonadi 
within the Meego project. So from netbooks to smartphones.

Bye,
-Riccardo
-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화
_______________________________________________
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/