On 13/04/14 21:58, Heyns Emiliano wrote:
> So... as Patrick pointed out earlier and I might now begin to grasp...
> the target-config is the receiving end of the sync pair (Patrick said
> this verbatim... I think I now understand what he means).
> local://@context always points to target-config@context,
Yes
> and as
> target-config@context has an property called 'uri' pointing to a data
> source in @context, we have a full specification of the second half of
> the pair.
Not quite. If I understand correctly (Patrick?), the Xmn's for each
source within target-config@context have a uri property. So the uri in
the sending end's Xmn get matched against one of the Xmn's in the
receiving end's target-config to select the source on the receiving side.
> syncevolution --configure syncUrl=local://@OtherContext peerIsClient=1
> Source@Peer
I normally set up Peer@Source with the local URL and the peerIsClient.
But there is no reason it wouldn't work the way round you describe.
> means:
> - side a: {source: @AhDamnIDontKnow.Source, peer:
> @AhDamnIDontKnow.Source}, connects to
> - side b: {source: @OtherContext.target-config.uri, Peer:
> @OtherContext.target-config}
No... I think it means...
- side a (sending side): {context: @Peer, peer: Source@Peer}, connects to
- side b (receiving side): {context: @OtherContext, peer:
target-config@OtherContext}
> After this, calling
>
> syncevolution --sync Source@Peer
>
> would sync exactly this one pair. Except I have no idea in which
> context. Frig, this is complicated.
No. It syncs every Xmn from Source@Peer (which has "sync" not equal to
"none") and tries to pair it with a relevant Xmn from
target-config@OtherContext. So...
- side a (sending side): {context: @Peer, peer: Source, Xmn: each one in
turn (with sync!=none), URI: taken from each Xmn}, connects to
- side b (receiving side): {context: @OtherContext, peer: target-config,
Xmn: the one with the URI matching, source: the one corresponding to the
Xmn}
> If I'm understanding this correctly (and that would be a first), this
> means that if I'm setting up a sync for my Google contacts and my Google
> Calendar, I'd need separate contexts for those, as I'd need a separate
> target-config for each, and each context can have only one of those.
You can have several sources in the context, because it is the Xmn's
which pair up and which have the important properties (like uri). You
would only need separate contexts if you needed to specify different
usernames.
> If I'd want to sync an exchange contacts folder with a local vcards
> folder with my google carddav folder, that's mean I'd have to set up
> ContactsFolder@Exchange and ContactsFolder@Google, and give them both
> the same target-config in for example @Local, which has an 'uri'
> property pointing to a file datasource with vcards, setting up a
> hub-and-spoke system. Please let this be correct.
Almost, but not quite. You would set up LocalFolders@Exchange and
LocalFolders@Google, and give them both the same target-config in
@Local. The uri's would be set up in the Xmn's (for example
"LocalFolders@Exchange contacts", "LocalFolders@Google contacts" and
"target-config@Local contacts"). That would be the hub-and-spoke system.
> If I'd then want to do
> the same for my Calendar, I'd need a new context because @Local cannot
> have the target-config anymore to be paired up with
> CalenderColder@Exchange/CalendarFolder@Google.
No. You could also set up "LocalFolders@Exchange calendar",
"LocalFolders@Google calendar" and "target-config@Local calendar", using
the same contexts and peers (but different Xmn's).
> What do you mean by saying 'target-config doesn't need anything'? At the
> very least I'd expect it would need 'uri' to be set to point to a fully
> self-contained data source, or a username/password if the datasource
> didn't have one.
The uri's are on the target-config Xmn's. You are probably right about
the username/password.
Graham
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
