Menu
▾
▴
opensync-devel
|
From: Bjoern R. <bjo...@go...> - 2010-01-10 12:45:23
|
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 |
|
From: Daniel G. <go...@b1...> - 2010-01-10 13:17:13
|
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 |
|
From: Michael B. <mb...@gm...> - 2010-01-11 08:30:25
|
On Sun, Jan 10, 2010 at 01:20:55PM +0100, Bjoern Ricks wrote: > SyncEvolution is well integrated into the gnome world (e.g. using eds as > backend). Well, I tried it a couple of days ago, and I would not call it "well integrated", at least not at the application level. AFAICT, it is a CLI application right now, which you have to trigger manually. There is a GUI called genesis-sync, but it is not integrated with evolution or anything else either. And I am not sure about mobiles/bluetooth - what I saw so far looked like syncevolution was more targetted at sycning with Syncml servers over http. So while the framework might be more GNOMEish and better accesible, I think the user-facing part has not been adressed yet. Disclaimer, I have not actually used syncevolution to sync anything yet, just tried to get rolling. Michael |
|
From: Felix M. <fe...@de...> - 2010-01-11 09:07:34
|
Hi, Am 11.01.2010 09:20, schrieb Michael Banck: > On Sun, Jan 10, 2010 at 01:20:55PM +0100, Bjoern Ricks wrote: >> SyncEvolution is well integrated into the gnome world (e.g. using eds as >> backend). > > Well, I tried it a couple of days ago, and I would not call it "well > integrated", at least not at the application level. AFAICT, it is a CLI > application right now, which you have to trigger manually. There is a > GUI called genesis-sync, but it is not integrated with evolution or > anything else either. there are two new GUIs sync-ui-gtk and sync-ui-moblin. You have to enable them on ./configure ... > And I am not sure about mobiles/bluetooth - what I saw so far looked > like syncevolution was more targetted at sycning with Syncml servers > over http. See <http://syncevolution.org/development/sync-phone> regards Felix |
|
From: Tino K. <tin...@ti...> - 2010-01-11 13:27:20
|
On Mon, Jan 11, 2010 at 09:20:25 +0100, Michael Banck wrote: [...] > And I am not sure about mobiles/bluetooth - what I saw so far looked > like syncevolution was more targetted at sycning with Syncml servers > over http. The mobile devices can also sync to that SyncML server over HTTP. I'm using it this way to keep my desktop, notebook and Nokia mobile phone in sync for contacts and calendar. > So while the framework might be more GNOMEish and better accesible, I > think the user-facing part has not been adressed yet. I think genesis-sync is a very useful tool. You can trigger a sync manually or let it sync periodically. It can also do special sync operations like "sync one way from server", if you messed up your local data for some reason. Regards, Tino |
|
From: Patrick O. <pat...@gm...> - 2010-01-11 09:09:18
|
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/ |
Thanks for helping keep SourceForge clean.
X