8:14 p.m.
On Tue, 2014-04-15 at 11:50 +0200, Emiliano Heyns wrote:
On Mon, Apr 14, 2014 at 9:36 AM, Patrick Ohly
<patrick.ohly(a)intel.com>
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):
I suspect that running SyncEvolution as SyncML client is still more
common (and thus "normal") than running it as SyncML server. For the
sake of this discussion, "normal" sync is both, because it involves only
one sync config.
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.
It's matched based on the SyncML device ID, stored by SyncEvolution in
"remoteDeviceID" (for the SyncML client that connects to SyncEvolution)
and "deviceID" (for SyncEvolution itself).
The credentials are optional; one could also allow syncs without
checking them. SyncEvolution skips the check when username and password
are left empty.
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.
The SyncML client chooses which sources it wants to sync with. This is
what SyncEvolution as SyncML client does via the "uri" property.
It would be nice if SyncML had allowed some kind of automatic "I want to
synchronize the default address book", but that never got standardized.
Instead client and server must agree on the name (aka uri) of that
default address book.
Note that SyncML also allows for server-initiated sync sessions. This is
used with phones connected via Bluetooth, where the user interacts with
some software running on a more capable device (usually a computer)
which then becomes the SyncML server.
The target-config specifies a faux syncml client, who (conceptually)
initiates the sync.
It's better to think of a local sync as being initiated from the server
side, the "originating config" as I started to call it.
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.
It's the other way around. The Xmn properties of the originating config
specify the sources and how they are paired with the sources on the
target side. The syncURL pointing to that context is set in the
originating config. The syncURL in the target config is not used for the
local sync itself; it can be used instead as placeholder for a common
URL for the involved sources on the target side.
--
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.