On 04/04/2014 10:52:15, "Patrick Ohly" <[email protected]> wrote:
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.
When you say 'source', does that mean 'data source' from the terminology
list? Is this structurally of the same kind as the <source> mentions in
the synopsis section?
So such a (data?) source ties a few elements together:
1. A backend, as described in the terminology section: the technical
kind of container
2. A database, as described in the terminology section: the location of
the container
3. a database format (not described in the terminology section): the
format of the things *in* the container
From the synopsis section I am led to believe that @default is a
<config>. I take it this is a source config, but (assuming this is a
clean environment):
1. Is this source config created as a side-effect of creating this data
source?
2. What does this config hold, and what, if anything, is it associated
with?
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:
When you say 'context' here, I take that to refer to the context as
described in the terminology section; in that description, a sync or
source config is defined inside a context. But if I look at the
definition of the local source above, that seems to be defined properly
before we ever got to a context. Unless the @default is the context, but
that conflicts with the naming in the synopsis section.
syncevolution --print-databases \
backend=carddav \
[email protected] \
databasePassword=foobar \
database=https://www.googleapis.com/.well-known/carddav
That again translates well to how I understood the concepts above:
1. A backend: a 'carddav' 'container', which describes how in general to
get stuff in and out of this kind of container
2. A database: location of the carddav container
3. a database format: implied by the backend
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.
What does 'peer' mean here? How do I differentiate between a 'peer' and
a 'context'?
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
So: configuration of a *data source* 'main-google-addressbook', which
creates(?) a config or a context called '@google', if my interpretation
above is correct. (it needs a '\' after the database BTW). But I don't
know whether I should label @google a config or a context here.
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.
I'll keep that in mind. I'll work out how to do headless oauth later,
for now I've set up an app-specific password.
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.
I also at this point cannot assume I properly understand what a
target-config is, but if we can do without for now that's fine by me.
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.
OK, so this sets up a 'sync config' from the terminology section, a
target config being "a special *kind* of sync config'. A 'sync config'
is then intrinsically *one* side from a pair of entities involved in a
synchronization. This sync config attaches itself in some way to the
context @google; the properties it specifies do not attach to the
context @google, but to the sync config 'target-config@google'. Correct?
It sets this up as a sync config because either:
1. syncURL is present, or
2. target-config (literal) is present
On 'sync config' the terminology says: "A sync configuration defines how
to access a peer: the protocol which is to be used, how to find the
peer, credentials, etc. Peers might support more than one protocol, in
which case multiple sync configs have to be created."
But the data sources as defined above already seem to include all the
information on how to find the peer, and includes the credentials, and
also seems to include or uniquely imply the one protocol supported. The
README states that the part after 'target-config' must be a context, but
as outlined above, it's not entirely clear when these contexts come into
existence.
Also, when reading the 'target config' section, it says that it holds
"sync properties that are necessary to access databases on the other
side of the local sync". But:
1. It seems that this data is already included in the source set up
earlier
2. Local sync is differentiated from a 'normal sync', but I don't know
what a 'normal sync' is
3. the local sync syncs with a remote server/device?
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.
So the @google *context* has a datasource 'main-google-addressbook'
then? And the context @google comes into existence upon first reference?
Then what data is held by the context? How does SE know upon first
reference what properties to attach to the context, and which to the
data source?
syncevolution --configure \
sync=two-way \
target-config@google main-google-addressbook
OK, so this says: "Take sync config 'target-config@google', which is
attached to context '@google'. This sync config tells you all you need
to know how to access data source 'main-google-addressbook', apart from
the actual backend/databaseUser/databasePassword/database, which you can
take from data source 'main-google-addressbook'". But what does it take
from the sync config that is not already included in the data source?
The next step is to set up the actual connection between @default and
@google.
So contexts are connected in a sync scenario? Not data sources?
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
This uses the magic word 'syncURL', so this sets up a sync config?
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
So, this pairs data source main-google-addressbook with
my-vcard-source. Is the last datasource on this command line by
necessity local, or would
syncevolution --configure \
sync=two-way \
uri=my-vcard-source \
default@google main-google-addressbook
have accomplished the same?
And now sync:
syncevolution --sync slow google@default
So this syncs *all* paired-up datasources in google@default? what label
from the terminology list would you give to 'google@default'?
When following these steps, you will notice that creating the
target-config included a check whether main-google-addressbook is
usable.
I didn't notice that that is what it was for :) Is this why the access
data repeats between setting up the data source and the sync config?
This is part of some special semantic for creating new sync
configs: if no sources
Sources? Plural?
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
OK, so this sets up a sync config *without* attaching it to a context?
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.
OK, so that means 'usable' in the sense that it if you give it a
username and password, it knows which data sources are offered by
memotoo, and can than figure out for itself for each:
1. the backend
2. the database
3. the database format
but what is the meaning of the 'memotoo' at the end? It's not a data
source I think, because the datasources memotoo contains will differ on
these properties. Is it a context?
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.
How do contexts and peers relate (if at all?)
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.
OK, so I think I have the terminology on 'data sources' clear. Just to
reiterate: a data source would point to exactly one collection of
exactly one kind; a data source would not hold both calendar and
contacts items. Correct?
Questions, questions.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
