12:51 a.m.
[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/syncevolution@syncevolution.org/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.