Hi Patrick,
On Tuesday 04 January 2011 14.51:29 Patrick Ohly wrote:
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.
Yes, to some extent.
But then most PCs these days are networked, and thus clients as well as
servers at the same time. The same is increasingly true for phones.
A phone connecting over your LAN to your desktop PC and a phone connected to a
server are not all that different, especially as email always requires some
server somewhere to talk to, and that server might very well be your local
desktop, as Opera has demonstrated.
So the use case of "no server whatsoever" is increasingly limited to "no
email, just some private non-shared calendaring on a non-networked desktop" -
and that is a use case I see shrinking in importance, especially as the
alternatives become more widely available and cheaper.
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.
Actually both approaches allow you to keep your data on your own devices these
days if you want.
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
That is interesting.
How will you avoid the issues that OpenSync faced when becoming more modular?
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.
Both points are true. I would also say that SyncML has the conceptual flaw of
assuming dumber devices than todays devices actually are.
As soon as you control both sides of the sync, SyncML is suitable
for
PIM sync.
True. But then that is intraoperability. Interoperability comes into play when
you only control one side. And most real-life issues typically arise out of
the fact that controlling both sides is usually not a given.
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.
I'd be very interested in that, please keep me up to speed.
Best regards,
Georg
--
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
Zürich, Switzerland
e: greve(a)kolabsys.com
t: +41 78 904 43 33
w:
http://kolabsys.com
pgp: 86574ACA Georg C. F. Greve