Emile,
I have attempted to provide some explanations. Of course, like you, I
find the configuration structure difficult to understand so Patrick may
need to make corrections!
On 02/04/14 09:49, Emiliano Heyns wrote:
> I can now access the GCal database, but if I don't pass the credentials
> on the command line, it fails or hangs. Can I store these in gconf too?
> This is how I'm setting it up:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> syncURL=https://www.google.com/calendar/dav/%u/user/?SyncEvolution=Google";
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?SyncEvolution=Google";
SyncEvolution normally stores usernames and passwords itself.
ActiveSync is unusual in that it uses gconf and keyrings. So, for the
Google access, you need to give the usernames and passwords to
SyncEvolution.
> syncevolution --configure --template none backend=caldav
> username=${GOOGLE[email]} $OPTIONS target-config@Google
> And this is how I'm printing the DB:
>
> OPTIONS=
> OPTIONS="${OPTIONS} password=${GOOGLE[password]}"
> OPTIONS="${OPTIONS}
> database=https://www.google.com/calendar/dav/${GOOGLE[calendar]}/events?SyncEvolution=Google";
>
> syncevolution --print-databases username=${GOOGLE[email]} backend=caldav
> $OPTIONS
--print-databases is standalone -- it doesn't use (or need) any configs
set up. That is why you have to inclue the username and password on the
actual command line itself to use --print-databases.
> Setting up the actual sync (exchange-local so far -- on to google once I
> understand this) is still mystifying. This is what works (for Exchange
> <-> Local), but I have no idea why:
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).
Now make the scenario a little more complex again. One or other or both
of the sources involved could be Exchange or Google or Webdav and might
not be physically located on either the first host or the other host.
So, using this, you could set up a sync which runs on FirstHost, and
accesses an Exchange source on ExchangeHost instead of local files. Or
maybe the source on OtherHost would be a Google database, on GoogleHost
instead of local files.
In any of these cases, we have two separate source configs (one on
FirstHost called @Local, and one on OtherHost called @OtherHostFiles),
one sync config set up for each source config: OtherHost@Local on
FirstHost and FirstHost@OtherHostFiles on OtherHost. In each case, the
source databases have to be defined and the peer information has to be
defined on each one to know how to connect to the other (whether to make
a conection or wait for an incoming connection, which source folders to
expose to the other end, whether to print changes during the sync, etc).
I think this is reasonably logical -- each host needs to know how it
should talk to the other host.
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://.
[By the way, Patrick, I think things would be easier to understand if it
was possible to setup the local syncUrl as "local:://peer@source" and
"peer@source" would be the corresponding sync config instead of the
special name target-config@source. It may be there is some reason not
to do that, but I have always thought of target-config as a horrible hack]
That was probably far too long, but having written it, here are my
answers to your remaining questions...
>
> # TODO: I thought "syncevolution --configure" set up a peer... is the
> x@y automatically a sync config between peers? Does this set up all
> possible (cal-cal, contact-contact) pairings?
> syncevolution --configure --template none username= password=
> printChanges=1 Exchange@Local
--configure sets up either a source or a sync (peer) config, depending
on whether there is peer name before the @. In this case, it is setting
up a sync config (for a peer). This defaults to setting up the details
for all sources (folders) within the named source, so it is telling
SyncEvcolution that it will expose all folders defined in the @Local
source when you use the Exchange@Local sync config.
> # TODO: Seems to be necessary but I don't know what it does.
> syncevolution --configure syncUrl=local://@Exchange peerIsClient=1
> Exchange@Local
This could have been combined with the previous command. It is
providing more details for how SyncEvolution should communicate with the
peer when you use the Exchange@Local sync config.
The most important detail it is providing is how to contact the remote
side of the sync (the OtherHost, in my explanation above). In this
case, it is saying "use the local optimisations -- the remote side of
this sync is on the same host and uses a sync called
target-config@Exchange). Note that the text "Exchange" in the two
places it appears in this command are completely unrelated. They could
be replaced with Foo and Bar and everything would still work (as long as
they were replaced in the other comamnds as well, of course).
> # TODO -- what is the meaning of 'uri=contacts' here? The docs say "is
> added to the end of the server URL". Is this then the actual sync setup
> between contacts-exchange and contacts-local?
> syncevolution --configure sync=two-way uri=contacts Exchange@Local
> contacts
> syncevolution --configure sync=two-way uri=calendar Exchange@Local
> calendar
Here you are setting more details of how to contact the other side of
the sync. However, these details are actually different for the
different folders (in the earlier commands, the details applied to all
folders/sources that are part of the source).
"uri" is used to set the name that the other side uses for this folder.
So, for example, you might have a contacts folder called "business" and
one called "personal". Assume you have two phones (one personal, one
business) and each phone can only sync with one contacts database, and
expects that database to be called "contacts". When syncing with your
personal phone, you might use "syncevolution --configure uri=contacts
MyPhone@Local personal" and for your work phone you might use
"syncevolution --configure uri=contacts WorkPhone@Local business". In
other words, in some syncs you expose "personal" as if it was called
"contacts", in others you expose "business" as if it was called "contacts".
In most cases, the uri should be the same as the source name.
The sync= option is used to define whether that particular source folder
should actually be synced at all (in that sync config). If you decide
that you don't want to sync that folder at all, use sync=none. I have
no idea if other values for that option are meaningful.
> # TODO -- why are we setting up two-way sync here again? Isn't this
> part of the peer setup I did earlier?
> syncevolution --configure --template none username=${EXCHANGE[email]}
> password= printChanges=1 target-config@Exchange
Now we get to the other side of the sync. The earlier commands set up
the @Local side of the sync -- the side to do with the local database.
Now we set up the details for the other end of the sync, the part which
runs on OtherHost in my explanation (except that it is actually on the
same host). Maybe this does duplicate some information we have already
configured on the other side but the SyncEvolution local optimisations
don't detect that. This is treated as almost separate (the only link
between the two configs is the syncUrl=local:... set up earlier).
>
> # TODO -- What is the meaning of the last contacts/calendar in these
> lines? Shouldn't this be part of the peer setup rather than the sync setup?
> syncevolution --configure sync=two-way uri=contacts
> target-config@Exchange contacts
> syncevolution --configure sync=two-way uri=calendar
> target-config@Exchange calendar
You are setting up the peer information for the @Exchange side of the
sync. Telling it about how to do the sync with the other side (the
@Local side in this case). In this case you are specifying that the
Exchange source "calendar" should be exposed to the other side as
"calendar" (seems sensible).
I hope that has helped a little, not just made things more confusing.
Now Patrick can correct it!
Graham
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
