On Mon, 2014-04-14 at 11:30 +0200, Ove Kåven wrote:
> Den 14. april 2014 09:36, skrev Patrick Ohly:
> >> To do that, the original sync config's syncURL would no longer point to
> >> a remote SyncML server, but, by using "local:", it can be set to point
> >> to a local SyncML server within SyncEvolution itself, using a different
> >> configuration context. For simplicity, that SyncML server is always
> >> called "target-config", though it's otherwise just a completely normal
> >> sync config, nothing special about it configuration-wise. It's just the
> >> peer that SyncEvolution talks to internally when it's asked to talk to
> >> itself.
> >
> > Actually, the originating side acts as SyncML server and the
> > target-config as client, hence the "peerIsClient=1" in the originating
> > side.
>
> Ah, I thought that option was for syncmode ("refresh-from-client" etc)
> and things like that.
In a way it is, because refresh-from-client/server depends on the role
of each side. It will always refer to the internal SyncML server resp.
client, not the remote server that may or may not be used by a backend
on either side.
Consider direct syncing between an ActiveSync server and a WebDAV server
and it becomes painfully obvious that the traditional
"refresh-from-server" is no longer useful.
Because they exposed implementation details, refresh-from-client/server
were replaced by refresh-from-local/remote, with the better defined
(although not always intuitive) "local" side being the one which
triggers the sync.
> > The property has to be set because at some point it might make
> > sense to allow reversing the roles. If that happens and configs are in
> > use where the property is not set, we wouldn't be able to use it.
>
> So if you did, would that break "refresh-from-client/server"?
It would reverse the direction of these two options, so yes.
refresh-from-local/remote would continue to work as before.
--
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]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
