------ Original Message ------
From: "Graham Cobb" <[email protected]>
To: [email protected]
Sent: 13-4-2014 21:49:45
Subject: Re: [SyncEvolution] Getting the concepts clear (Was:
Configuring a target)
On 13/04/14 19:45, Heyns Emiliano wrote:
In addition to this we have 1a: Target-Configs. I think a
target-config
is really what binds two Sync Specifications together to form a full
sync pair, but I've lost track how; the syncURL seems to play an
important part here, but it has differing usage, sometimes it's used
to
hold a real syncURL (such as
https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google
<safelink(32ce5049-7ac5-4675-8fe9-bf7f5dcf1a2a):https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google>),
another time it's use to point to something inside the syncevolution
config (such as local://@Context). It does feel a bit like a
target-config is only a 'kind of' Sync Config/Peer because the
required
data could be shoe-horned into its data-structure, rather than there
being real similarity in intended behavior of these two kinds -- I
wouldn't mind to be corrected on this one.
If we put aside the special case of using target-config with things
like
--print-items, then I think target-config makes some sense to me...
If you were syncing two different systems each running SE, using
SyncML,
then on each server you would have to set up a peer to point to the
other side. One of them would have the syncUrl to make the outbound
connection with, the other would have information to route the incoming
connection to a particular sync-config and context. That makes sense to
me.
If we then consider a local connection, I think of that as just an
optimisation of the connection. It seems logical that you still need a
peer set up in each of the two contexts which are going to be connected
together. One has the syncUrl (local://@context), the other doesn't
actually need anything really but still exists and has to have the name
target-config@context.
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, 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.
syncevolution --configure syncUrl=local://@OtherContext peerIsClient=1
Source@Peer
means:
- side a: {source: @AhDamnIDontKnow.Source, peer:
@AhDamnIDontKnow.Source}, connects to
- side b: {source: @OtherContext.target-config.uri, Peer:
@OtherContext.target-config}
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.
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.
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. 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.
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.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
