7:35 p.m.
On Di, 2011-01-04 at 16:23 +0000, Georg C. F. Greve wrote:
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.
True. So the difference is less about connectivity and more about "how
is the server operated": user sets up the server himself, or uses a
service operated by someone else for him.
SyncEvolution falls into the "personal server" category, whereas the
others have explicit multi-user support. They can of course be installed
by one power-user just for himself, but I don't think that this is their
sweet spot or intended usage.
> 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.
But only my own server keeps my sensitive data out of the hands of
third-parties which might misuse it, like send invitations to all my
contacts - not unheard of...
> 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?
I expect that a different development approach will help. SyncEvolution
is extended piece-by-piece. I haven't done the exact math, but my
feeling is that new releases came out about every few months (including
bug fix updates). These pieces are small enough to be handled without
introducing regressions; strict testing helps with that.
Regarding modular: I don't intend to release modules (= backends) which
do not pass the same quality standards as the rest of SyncEvolution. I
could have included an Akonadi backend one year ago, but not at
production quality and I wouldn't have been able to support it, so
therefore it's still only in a source code branch.
The data modeling is already pretty modular, although I see room for
improvement. Some things, like enabling or disabling certain properties,
can only be done by copying a Synthesis profile - possible, but leads to
code duplication. I have ideas how to address that, once the need
arises.
There's no guarantee that SyncEvolution will ever be able to solve all
of the problems. Promising that would be dishonest. But my guess is that
it can go a long way. If it doesn't, so be it.
> 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.
Indeed. I mentioned it because SyncEvolution's "local sync" is based on
SyncML as internal protocol, and I wanted to make sure that this is not
seen as a weakness of the design.
--
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.