On Mon, Apr 14, 2014 at 9:36 AM, Patrick Ohly <[email protected]>wrote:
> Actually, the originating side acts as SyncML server and the
> target-config as client, hence the "peerIsClient=1" in the originating
> side. The property has to be set because at some point it might make
> sense to allow reversing the roles. If that happens and configs are in
> use where the property is not set, we wouldn't be able to use it.
>
>
So in a 'normal sync', which I understand to be a sync between any given
syncml client and SE acting as a syncml server, only needs (minimally):
1. a data source, which is a full specification of a database (kind:
events, memos..., storage engine=backend+format, location: database)
2. a sync config, which in this case would specify the remote syncml
*client*, and I'm guessing it would be matched based on username/password.
In such a case the syncURL would not be used, as it is up to the client to
know it, SE is just awaiting a connection. The sync config would know by
its 'unshared properties' (the Xmn entries) which data source(s) this
incoming client would be allowed to use, and it is up to the sync client to
choose what kinds of entries to offer for sync.
When the connection comes in, SE then has exactly enough information for
authentication (contained in the sync config), authorization (contained in
the Xmn entries), and what to sync the incoming client with (the data
source authorized for in the Xmn). The syncml protocol (which I do not
know) then must either allow for selection of a data source of a given kind
("I want to sync contacts with contacts storage X on the server"), or there
can be at most one Xmn entry per sync-config/datasource/kind combination,
so that "I want to sync contacts as user U" would be fully resolvable to
that one Xmn entry.
EAS and WebDAV are not considered sync engine technologies within the scope
of SE, but data storage engines. While it would be in principle possible to
set up a pair of server-based backends, for simplicity and debuggability,
we set up a hub-and-spoke system with the hub a simple backend such as the
'file' or 'eds' backends.
The target-config specifies a faux syncml *client*, who (conceptually)
initiates the sync. Instead of providing a username/password/kind to
perform auth/authz/database selection, a target-config is considered a
'trusted' client, and salient properties are selected as follows:
1. Authentication: assumed valid
2. Authorization: assumed valid, the Xmn properties of the target-config
simply specify what sources it (as a client) wishes to sync.
3. source(+kind) selection: the syncURL of the target-config points to a
context; in this context, the data source as named by the uri property in
the Xmn is selected.
The target-config might contain password/username values, but these are
passed to the source selected in the linked context, if required, so the
associated backend *with that source* can establish the connection.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
