opensync-users

[Opensync-users] Comparison between OpenSync and SyncEvolution

[Bjoern R. <bjo...@go...>]

Hi,

I am currently at the KDE PIM Meeting and yesterday I attended to a talk
about SyncEvolution and syncing in general. Patrick Ohly had presented
some slides about SyncEvolution and I also talked to him in private.
Afterwards it became clear to me that there are some differences between
OpenSync and SyncEvolution that I want to share with the list. Patrick
please correct me if I am wrong in any comment and also if I forgot some
features.

The general approach of SyncEvolution was and is to solve current
syncing problems. That's completely different to OpenSync. OpenSync
wants to be a general framework for mostly all PIM synchronization
problems. Therefore our architecture is more complicated and difficult
to understand. SyncEvolution is based on syncml and uses syncml to
communicate with their peers. In OpenSync syncml is only one possible
client. SyncEvolution also has a dbus daemon and provides a GUI.
OpenSync is only concentrating on the framework/library and does provide
osynctool for testing. There is no dbus integration in OpenSync at all.
SyncEvolution is well integrated into the gnome world (e.g. using eds as
backend). If I understood Patrick correctly SyncEvolution isn't able to
sync with different backends at the same time (at the moment). The
OpenSync architecture always supported different backends/peers (e.g.
evolution and gnokii) and is loosely coupled to syncml. With OpenSync it
is also possible to sync different backends/peers at the same time
because of the sync group feature. In OpenSync the sync plugin are able
to run in different threads, processes, etc. OpenSync contains an IPC
layer and plugins don't have to care about that in detail. This feature
is completely missing in SyncEvolution. In my opinion this is a big
advantage of OpenSync. In the opposite a cool feature of SyncEvolution
is the scriptable data conversion using libsynthesis.

regards
Bjoern

Re: [Opensync-users] [Opensync-devel] Comparison between OpenSync and SyncEvolution

[Daniel G. <go...@b1...>]

On Sunday 10 January 2010 01:20:55 pm Bjoern Ricks wrote:
> In the opposite a cool feature of SyncEvolution
> is the scriptable data conversion using libsynthesis.
> 

I'm also very interested in this. That's also the reason why I spent so much 
time in making sure that we can support multiple common formats (e.g 
XMLFormat, and others ...). The idea is to make use of libsynthesis data 
conversion code for better support of the vformats ... and keep XMLFormat for 
compatibly reason or more simpler API for plugins which don't have vformats.

(No, xmlformat is not going to be dropped ... at least as long plugins still 
using it. If there is one way a better alternative we can easily switch to it)


Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-users] Comparison between OpenSync and SyncEvolution

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

On Sun, 2010-01-10 at 13:20 +0100, Bjoern Ricks wrote:
> The general approach of SyncEvolution was and is to solve current
> syncing problems.

I describe the SyncEvolution approach as "from the ground up": start
with something that can be solved, do it well and release, then continue
with the next problem. I started with a SyncML client for EDS. Mac OS X
Address Book was added later. A backend for XMLRPC and the Maemo
calendar API were written by contributors. As of this weekend, there's
also a rudimentary Akonadi backend. For 1.0, we add SyncML server
support. Non-SyncML protocols might come once that works.

I think the way towards non-SyncML protocols like PBAP is to wrap them
in a backend and talk to the central server via SyncML as the
SyncEvolution-internal protocol.

> If I understood Patrick correctly SyncEvolution isn't able to
> sync with different backends at the same time (at the moment).

Correct. That prevents the "wrap other protocols" approach described
above. But this is purely a simplification of the implementation, not a
conceptual problem. We'll add it once it becomes necessary. The same
applies to out-of-process backends.

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