On Thu, 2014-04-03 at 13:38 +0000, Emiliano Heyns wrote:
> 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'.
Let's break this apart, using SyncEvolution terminology.
First, you don't have a local storage "which syncs". You have a local
storage, full stop here. A local storage gets synced, but that comes
later.
So you define first what that local storage is:
syncevolution --configure \
backend=file \
database=/tmp/my-vcards/ \
databaseFormat=text/vcard \
@default my-vcard-source
mkdir /tmp/my-vcards/
This creates a new source called "my-vcard-source" which uses the file
backend to access files in /tmp/my-cards.
SyncEvolution doesn't have a "remote 'device' of type 'google'", because
"Google" is not something that SyncEvolution knows about. You need to
translate that into SyncEvolution concepts, and that depends on how you
want to achieve your goals. Google servers support(ed) SyncML,
ActiveSync and CalDAV/CardDAV. Let's focus on the latter, because that
is what is officially supported by Google.
That means in SyncEvolution you have to define a source which accesses
one particular address book or calendar via CardDAV resp. CalDAV. For
the sake of consistency let's use a separate context for it (*). First
we need to pick the right database:
syncevolution --print-databases \
backend=carddav \
[email protected] \
databasePassword=foobar \
database=https://www.googleapis.com/.well-known/carddav
carddav:
Address Book
(https://www.googleapis.com:443/carddav/v1/principals/john.doe%40googlemail.com/lists/default/)
<default>
syncevolution --configure \
backend=carddav \
[email protected] \
databasePassword=foobar \
database=https://www.googleapis.com:443/carddav/v1/principals/john.doe%40googlemail.com/lists/default/
@google main-google-addressbook
Beware that you may have to create a per-app password for SyncEvolution
if you enabled two-factor login. Google is also very restrictive about
number of request when not using OAuth. I frequently got 403 errors
about usage restrictions with an error text asking to register the app.
Retrying a bit later then works again.
Configuring a target-config first would have helped a bit to reduce
typing, but not much. I'm skipping it because it is not required at this
point and would have detracted from the core concepts.
Now that you have two sources defined, they can be used to access items
with --import/--export/--print-items/... etc:
syncevolution --export - \
@google main-google-addressbook
Now it is time to set up syncing. First we need the target-config. For
the sake of the example, let's set a non-default loglevel for operations
on the target side and disable the printing of changes on the Google
side:
syncevolution --configure \
printChanges=0 \
loglevel=3 \
syncURL=none \
target-config@google
Remember that the command line is doing sanity checks when creating new
configs to catch typos, so we have to confirm explicitly that this new
config is meant to be created without a syncURL.
Now we need to enable access to the main-google-addressbook. It would be
inactive otherwise. This is useful when configuring a peer in a context
which has many different sources defined, but you only want the peer to
have access to a certain subset of them. Any "sync" value other than
"none" is okay here.
syncevolution --configure \
sync=two-way \
target-config@google main-google-addressbook
The next step is to set up the actual connection between @default and
@google. We want to choose sources explicitly, so disable all sources
which might be defined in the @default context:
syncevolution --configure \
syncURL=local://@google \
peerIsClient=1 \
sync=none \
google@default
Then pair the sources. We are doing that for only one pair of sources
here, but it could also be done for more.
syncevolution --configure \
sync=two-way \
uri=main-google-addressbook \
google@default my-vcard-source
And now sync:
syncevolution --sync slow google@default
syncevolution google@default
Slow sync prevention is enabled, so the initial sync has to be done as a
slow sync explicitly.
In the steps above I have focused on one small change at a time. It is
possible to combine the steps in a single command line invocation, for
example like this:
syncevolution --configure \
syncURL=local://@google \
uri=main-google-addressbook \
google@default my-vcard-source
Or like this, if we need to set source properties for different sources
in the same operation:
syncevolution --configure \
syncURL=local://@google \
my-vcard-source/uri=main-google-addressbook \
my-vcalendar-source/uri=main-google-calendar \
google@default my-vcard-source my-vcalendar-source
When following these steps, you will notice that creating the
target-config included a check whether main-google-addressbook is
usable. This is part of some special semantic for creating new sync
configs: if no sources are named explicitly, SyncEvolution will enable
all sources which are usable. In this case the check could have been
skipped because the source wasn't going to be enabled in that step
anyway because of "sync=none". The code is just not intelligent enough
to take that into account. Later, when changing properties like "sync",
no such sanity checks are done anymore.
The intention was to give users a single command that results in a
usable sync config without them having to say anything about particular
sources:
syncevolution --configure \
template=Memotoo \
username=john password=bar \
memotoo
If nothing has been configured before, this will check for the default
"addressbook", "calendar", "memo", "todo" databases and enable those
sources which are usable. The default depends on how SyncEvolution was
compiled. At the moment, the default backend and databases are EDS.
> 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.
That's because the first sentence is already wrong: @files and @google
are contexts, and the peer is the Google server. And you don't have sync
configs for a calendar or contacts folder, you have source configs for
them. Accessing data is different from syncing it. Syncing builds on top
of data access.
(*) Choosing separate contexts for both sides of a local sync was
required by SyncEvolution < 1.4. It was meant to enforce that a sync
does not involve the same data on both sides of a pair. But the check
was not fool-proof anyway (nothing prevents defining two different
sources in two contexts accessing the same data) and it turned out to be
more useful to use a single context in PBAP syncing, so I dropped that
requirement.
--
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
