Re: [Opensync-devel] Getting things back on track

[Patrick O. <pat...@gm...>]

On Sun, 2009-10-18 at 23:53 +0100, Paul Eggleton wrote:
> I just read a blog posting [1] by one of the Akonadi developers about some 
> discussions that have gone on at their recent meeting. It seems for now they 
> have given up waiting for OpenSync and are looking at alternatives.

They were looking at writing a SyncML client based on the Funambol C++
client library and a SyncML server based on libsyncml. The former kind
of works, but has its limitations. The same limitations are the reason
why I switched from Funambol to libsynthesis. A server requires quite a
bit of logic which is not in libsyncml (by design!), so they didn't get
it to work.

I suggested that using libsynthesis and/or SyncEvolution [1] would solve
both of their problems and the consensus in September was that this was
worth a try. The guy working on the SyncML support was on vacation much
of last month, so we need to pick up that discussion again.

> For OpenSync to be successful it needs to become a stable, working 
> synchronisation platform that application developers (and users) can rely on. 
> I feel like we're about 90% there, but we need to finish the last 10% or all of 
> the work that has been done over the last few years will be mostly wasted.

After the discussions I was involved in earlier this year, my perception
is a bit different. All the hard problems (data merging + conversion)
were pushed out into plugins, but no-one is writing these plugins
(conversion vCard 2.1 -> 3.0, vCalendar 1.0 -> iCalendar 2.0). I also
have my doubts whether it is possible with the current APIs. I tried to
understand its design and but didn't get very far.

My own approach with SyncEvolution is different: start with working code
which solves these problems (the engine from Synthesis) and build a
complete solution around it. For those who haven't heard the news [2],
direct synchronization with one instance of SyncEvolution acting as
client and another instance acting as SyncML server is already possible.
We have SyncML/OBEX support almost implemented, so soon we'll be able to
try out local synchronization with SyncML capable phones.

I have ideas how this could be turned into a solution for other,
non-SyncML data sources. Basically I would do it like Henrik suggested:
use SyncML as the protocol between independent entities and writing
SyncML stubs for other data sources. But I don't want to use this list
for non-OpenSync discussions unless there is an explicit interest. I
wouldn't have posted here if you hadn't started questioning OpenSync
(and asked for alternatives) yourself.

[1] http://syncevolution.org/
[2] http://lwn.net/Articles/356712/


-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/