Architecture overview

This page is an attempt to explain key SyncEvolution concepts in a simpler way, primarily by focusing on the essential aspects and explaining how they relate to the on-disk config files. For the full reference, see the terminology section of the manual.


SyncEvolution uses hierarchical configuration. Its files are located at $HOME/.config/syncevolution (Let's call it configuration root)

At the highest level of a configuration there is one (or more)

Context

Contexts are profiles independent of each other. If a context is not explicitly noted, then default context is used.

In a filesystem a context is placed in the configuration root and is a folder containing:

  1. peers
  2. sources

and the context config which contains shared and global properties of the context.

A context may have multiple peers and multiple sources (in it).

Peer

A peer is a configuration of some peer to synchronize data to. This can be another device (like a phone), a server (like Google) or in some cases it may be the target config (more on it later).

A peer has its own configuration: this is where the remote part settings are: host, port, username and so on. AKA sync config.

Source (config)

Source is also known as Data source.

This generally represents a local store that holds all your precious PIM data.

The Source configuration is split into two parts: shared and per-peer.

  • shared configuration is placed in a context folder. It is shared by all the peers in the context. It contains the store information.
  • per-peer configuration is in the /sources/ folder. It determines how this peer synchronizes to this source. The sync configuration setting there determines the type of sync for this source syncs with this peer.

The [backend][backends] configuration setting determines the type of the store. This may be the Evolution or KDE addressbook, or calendar or plain file(s).

Each per-peer Source configuration has the uri configuration setting which points to the peer's "Database" that would be synchronized with the Source (e.g. contacts, calendar, etc.). This means that there may be a number of Sources syncing to a peer: one for contacts, one for calendar data, etc.

target config

is a special case of the peer. It defines a peer which would have the SyncML client role instead of the normal SyncML server role. With the target config the SyncEvolution starts internal SyncML server to serve the peer (which would be the SyncML client).

This allows following configurations:

  • local sync for synchronizing two local Sources
  • ActiveSync peer (which accidentally is not a SyncML server)