Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On Mon, 2014-04-14 at 13:14 +0100, Graham Cobb wrote:
Thank you for your contribution, Ove. Interestingly, I actually
find
this way of thinking about local sync (that it is a hack to sort of
extend SyncML to other protocols) unhelpful. As both you and Patrick
have mentioned that, I realise that this is how it came about, but I
tend to think it causes additional confusion as it makes non-SyncML
protocol access look like more of a special case (with its own rules to
be learnt) than is really the case with the (brilliant) way Patrick has
implemented it. Of course, I may be unique in this and others may find
it very helpful -- just a data point.
I prefer to think of local sync as purely an optimisation on a sync
which happens between SyncML entities which happen to be on the same
system (and which can be completely replaced with a normal SyncML sync
if they are on different systems).
Is there really a fundamental difference between your view and Ove's?
You both view it as a SyncML client<->server sync. The difference is
that Ove leans more towards considering that a hackish implementation
detail, whereas you see it as a first-class concept that users need to
know and understand.
In the context of SyncEvolution I think of WebDAV and ActiveSync not
as
sync protocols but primarily as database access protocols, and all the
database backends in SyncEvolution as being equal.
That's correct. WebDAV really isn't a sync protocol, it just has some
support for concurrent access to item collections without offering any
means for resolving conflicts. ActiveSync could be used as a sync
protocol (by relinquishing control over the local copy of the data to
the server); SyncEvolution doesn't use it like that and instead just
uses it to get changes and reading/writing items.
--
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.