On Wed, 2014-04-02 at 11:36 +0000, Emiliano Heyns wrote:
> OK, still working through these two messages, but first, the concepts:
>
> *Context*: a service that can host one or more *Sources*.
"service" isn't defined.
> *Source*: a folder hosted in a *Context* of a certain type (calendar or
> contacts).
Again, "folder" is ambiguous.
> *Config*: can be a *Source Config* or a *Sync Config*.
Right.
> *Source Config*: a *Source* hosted in a *Context* with added properties
> (key-value pairs)
Yes.
> *Sync Config*: a pair of one local and one or more remote *Source
> Configs* hosted on the *same* *Context* tied together, with added
> properties (key-value pairs)
Close, but not quite. There is no distinction between local and remote
source configs. There are just source configs in the context of the sync
config.
FWIW, here's the terminology section from the README. It's meant to
introduce concepts from scratch, i.e. nothing should depend on anything
not defined yet.
peer
A peer is the entity that data is synchronized with. This can be
another device (like a phone), a server (like Google) or
even the host itself (useful for synchronizing two different
databases).
host
The device or computer that SyncEvolution runs on.
database
Each peer has one or more databases that get synchronized (Google Calendar,
Google Contacts). Conceptually a database is a set of items where each
item is independent of the others.
data source
A name for something that provides access to data. Primarily used for
the configuration which combines backend and database settings, sometimes
also instead of these two terms.
local/remote
Synchronization always happens between a pair of databases and thus
has two sides. One database or side of a sync is remote (the one
of the peer) or local (SyncEvolution). For the sake of consistency (and
lack of better terms), these terms are used even if the peer is another
instance of SyncEvolution and/or all data resides on the same storage.
sync config
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.
Sync configs can be used to initiate a sync (like contacting a
SyncML server) or to handle an incoming sync request (when acting
as SyncML server which is contacted by the peer).
source config
Each data source corresponds to a local database. A source config
defines how to access that database, like a sync config does for
peers. This information about a local database is independent
of the peers that the database might be synchronized with.
Sync configs use these shared source configs and add additional,
per-peer settings to each of them that define how that local
database maps to a remote database in the peer. By default a source
config is inactive inside a sync config and thus ignored. It must be
activated by setting the unshared `sync` property to something other
than `none` (aka `disabled`).
In SyncEvolution's predefined configuration templates, the following
names for sources are used. Different names can be chosen for sources
that are defined manually.
* addressbook: a list of contacts
* calendar: calendar *events*
* memo: plain text notes
* todo: task list
* calendar+todo: a virtual source combining one local "calendar" and
one "todo" source (required for synchronizing with some phones)
backend
Access to databases is provided by SyncEvolution backends. It does
not matter where that data is stored. Some backends provide access
to data outside of the host itself (`CalDAV and CardDAV`_, ActiveSync).
configuration property
Sync and source configs contain configuration properties. Each
property is a name/value pair. Sync properties are used in sync configs,
source properties in source configs. The names were chosen so that
they are unique, i.e., no sync property has the same name as a source
property.
A property can be *unshared* (has separate values for each peer, therefore
sometimes also called *per-peer*; for example the `uri` property which
defines the remote database), *shared* (same value for all peers; for
example the `database` property for selecting the local database) or
*global* (exactly one value).
context
Sync and source configs are defined inside a configuration context.
Typically each context represents a certain set of sources. The values
of shared properties are only shared inside their context. That way
it is possible to define a second `work` context with a `work calendar`
source using one database and use the implicit `default` context for
a private `calendar` source with a different database.
context config
The shared and global properties of a certain context.
configuration template
Templates define the settings for specific peers. Some templates
are packaged together with SyncEvolution, others may be added by
packagers or users. Settings from templates are copied once into
the sync config when creating it. There is no permanent link back
to the template, so updating a template has no effect on configs
created from it earlier.
A template only contains unshared properties. Therefore it is
possible to first set shared properties (for example, choosing
which databases to synchronize in the default context), then
add sync configs for different peers to that context without
reseting the existing settings.
local sync
Traditionally, a sync config specifies SyncML as the synchronization
protocol. The peer must support SyncML for this to work. When the
peer acts as SyncML server, conflict resolution happens on the
peer, outside of the control of SyncEvolution.
In a so called `local sync`_, SyncEvolution connects two of its own
backends and runs all of the synchronization logic itself on the host.
target config
In addition to the normal sync config, a local sync also uses a target
config. This target config is a special kind of sync config. It defines
sync properties that are necessary to access databases on the other
side of the local sync. Sync configs can have arbitrary names while
a target config must be named `target-config`.
--
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
