------ Original Message ------
From: "Patrick Ohly" <[email protected]>
To: "Emiliano Heyns" <[email protected]>
Cc: "SyncEvolution" <[email protected]>
Sent: 13-4-2014 19:53:48
Subject: Re: [SyncEvolution] Getting the concepts clear (Was:
Configuring a target)
On Sun, 2014-04-13 at 07:42 +0000, Emiliano Heyns wrote:
The "Usage" document says this:
"The target config holds properties
which apply to all sources inside that context, like user name,
password and URL for the server. Once configured, the target config
can be used to list/import/export/update items via the SyncEvolution
command line. It cannot be used for synchronization because it does
not defined what the items are supposed to be synchronized with."
But username, password and URL are part of the peer, not of the data
source. Is this correct?
It depends. As a special case, the data source can use these three
properties as fallback when nothing is set specifically for the source.
So this specifies the outlier case then? It's not something I'd run
into for common usage.
Another run to see if I have my concepts straight.
A context is just a container. It holds some properties, but for normal
usage I can ignore them as they have sensible defaults.
A context contains 3 "kinds" of entities:
1. Sync Configs, which roughly correspond with entries in the
directories called 'peers' in the config directory. I think 'peer' is a
better name for what I think these do, BTW: they seem to be geared to
specifying how a remote 'side' (be it a device, a service, etc) can be
reached, broadly.
2. Source Configs, which roughly corresponds with entries in the
directories calls 'sources' in the config directories. I think 'source'
is a good name for these. A source describes a database, with relative
to a yet to be named peer. It seems possible that a source could be used
in combination with different peers, but all the examples I've found so
far seemed to assume that a source was set up with a specific peer in
mind; as such, it seems like in practice there is an hierarchy
context-peer-source.
3. Sync Specifications, which live in directories of the form
/<context>/peers/<peer>/sources/<source>/, and which describe how a
given Peer+Source can be synced, but doesn't yet specify who to sync
with. This doesn't really have a name yet, other than the Xmn Graham
introduced.
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),
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.
On a different tack, I am slowly starting to figure out what the various
command line calls mean in the HOWTOs that are available, and the
scripts that I've assembled, but this one still eludes me:
syncevolution --configure sync=two-way uri=calendar Exchange@Local
calendar
From what I can gather, this sets the properties on Xmn entries (because
only Xmn have these properties). But Exchange and Local are contexts;
the synopsis says this is a 'config', which I take to be a Sync Config
(which I've dubbed 'Peer' above), so I could imagine it'd set these
properties on an Xmn described by either m = <some peer inside Exchange>
or <some peer inside Local> and n = 'calendar' (a source in either
Exchange or Local), but I don't understand how SE figures out which peer
in which context, and how it figures out which context it should choose
source 'calendar' from.
WRT naming, in the most general terms, I would propose that if there is
an entity X, an 'X config' describes its salient properties. An X would
then be a kind, and an 'X config' an instance of that kind. That should
take away some of the confusion regarding when to use 'source config' vs
'source', and also 'sync config' vs 'peer'.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
