On 02/04/2014 12:57:27, "Graham Cobb" <[email protected]>
wrote:
Part of the confusion may be understanding the need for two sides to
the
sync. Here is my best go at explaining what is going on.
Firstly, forget about the actual task we are trying to do: think about
a
traditional sync done by SyncEvolution. In that case, SyncEvolution is
syncing a local database (files, Evolution, KDE, whatever) with some
remote device (mobile phone, etc). In that case, you set up two,
related
pieces of information: a "source config" (for example @Local), which
defines the local database you are trying to sync (and what folders it
contains -- known as sources), and a "sync config" (for example
MyPhone@Local) which defines how SyncEvolution communicates with the
peer, which actual folders should be synced to this particular peer,
what sorts of syncs should be done, etc.
If you have multiple phones, you might set up multiple sync configs for
the same source config -- each one tells SynceEvolution how to handle
syncing with that particular device peer (for example, you might sync
different source folders with different devices).
This works fine if the remote device is a SyncML device, such as a
phone. But it also works if the remote device is another instance of
SyncEvolution running on a different host. In this case, you would set
up another similar configuration on the other host (maybe you would
create a source config on that other host called @OtherHostFiles, and a
sync config on that other host called FirstHost@OtherHostFiles). Of
course, you would set up the sync configs involved (one on the first
host, the other on the other host) so that they would talk to each
other
(one would make the connection, the other would receive it).
Let's just stick with this one case; I have a local storage of type
'file', which syncs one calendar and one contacts folder with a remote
'device' of type 'google'. The way I see it, I have two peers: @Files
and @Google. @Files would be a 'source config', and @Google a 'sync
config' -- but @Google is not a 'sync config' as the Google 'device' has
multiple 'sync configs': one for a calendar, one for a contacts folder.
So I'm already lost at this point.
The confusion comes when both sides actually run on the same host, in
the same SyncEvolution instance. That is what we are doing in your
Exchange<->Local sync example. In this case, SyncEvolution optimizes
away some of the actual connection details but it doesn't optimize away
any of the source or sync configs. That is why you end up having to
create a source config for the local files (@Local) and a sync config
to
tell it what to sync with (Exchange@Local) and also a source config for
the Exchange server (@Exchange) and a sync config to tell it what to
sync with (target-config@Exchange). The reason the latter has to be
called "target-config" is to do with the optimisations SyncEvolution is
doing to avoid having an actual SyncML TCP connection between the two
sides. It is for the same reason that in Exchange@Local you have to
setup a URL as the form local://.
OK... I think I can sort of follow the reasoning behind this, but to
translate the terminology into actual SE entities... augh. So if I only
want to sync *one* google calendar with *one* file-based store, what
combination of peers/databases/data sources/source configs/sync
configs/target configs/contexts/backends would I end up with?
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
