On Tue, 2014-04-15 at 11:50 +0200, Emiliano Heyns wrote: > 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):
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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
