[excluding the OpenSync list] On Di, 2011-01-04 at 10:49 +0000, Georg C. F. Greve wrote: > On Tuesday 04 January 2011 10.04:39 Patrick Ohly wrote: > > Let me add the SyncEvolution list, because the technical information may > > be relevant. For those who see this for the first time, it started with > > an open letter that I sent to the OpenSync list asking whether it really > > still makes sense to continue with two different projects instead of > > focusing on one: > > FWIW, there are several other projects dealing with synchronization to mobile > devices, e.g. Z-Push, which is used by Kolab, Zarafa and Zimbra for > synchronization with ActiveSync capable devices. [...] > But Z-Push is not the only implementation that is being worked on, AFAIK the > Horde project is also working on another ActiveSync stack. Simultaneously > there is the Syncphony project for Kolab by tarent. And there is of course > still Funambol, to which Syncphony also connects. More approaches and > projects > are likely to exist.
I think the key difference between those and OpenSync/SyncEvolution is that the latter two aim at supporting synchronization without depending on a specific service. The former all seem to be based on extending a web service. Both approaches are valid and complementary. I personally like the possibility to keep my data on my own devices, so local sync is important to me. Speaking of ActiveSync, are you aware of any client-side implementation in the open source? I knew about Z-Push (which is server-side, right?). I haven't checked the Horde pointer, but given that Horde is a groupware solution, I expect it to also cover only the server side. > The appealing part of OpenSync to me was the idea to allow multiple protocols > and data pathways and that they do not always necessarily involve a server. > While the former part may be too complex, as Patrick pointed out, and the > latter may become less important as connectivity gets cheaper, these were > interesting goals and the reason I experimented with it several years ago and > kept following this list. > > My understanding of SyncEvolution is that it is based on SyncML only. Historically, yes, but not anymore. See also my reply to Graham and the "local sync" mail thread here on this list: http://www.mail-archive.com/[email protected]/msg01419.html > While incorporating some good ideas, SyncML also has some systematic > weaknesses. These are at least in part addressed through the device matrix of > SyncEvolution. But at the same time the vendor support seems to be waning, > including at Nokia, the previously largest champion of SyncML. SyncML has had interoperability issues due to its loose definition. Vendors also got stuck supporting the same old data formats and devices, instead of adapting to more modern needs like iCalendar 2.0. As soon as you control both sides of the sync, SyncML is suitable for PIM sync. It is less suitable for high volume data transfers, which is better covered by other means. > So in your mind, would a merged project continue on the SyncML only path, or > would there be plans to change the focus of the project to include other > protocols? There's definitely a need for additional protocols and already some substantial work towards that. Not all of it is in the open source yet; please check again end of the month. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
