Hello! It's getting more accurate, but it's still not 100% there.
On Wed, 2014-04-16 at 08:12 +0000, Emiliano Heyns wrote: > On 15/04/2014 12:14:15, "Patrick Ohly" <[email protected]> wrote: > The target-config specifies a faux syncml server, It's more like a client in a server-initiated sync. > which (conceptually) awaits the incoming connection. This incoming > server must know what data stores it has available; this is registered > in its Xmn entries, "it" and "its" is ambiguous. I think you mean the right thing: "This incoming server must know what data stores the target config has available; this is registered in the incoming server's Xmn entries". > The SyncML client chooses which sources it wants to sync with. This is > what SyncEvolution as SyncML client does via the "uri" property, "client" has to be "server" here if you want to be technically correct, and consistent with the user-visible "peerIsClient" property. > stored in the Xmn entry that ties together the client side with the > target-config; the uri property points to a data source inside the > context that the target-config lives in. The data source pointed to in > the Xmn entry must match the kind of the data source pointed to by > uri@target-config-context. > > After setting up, for example: > > "client": context=C1, source=S1a of type 'contacts', S1b of type > 'events', sync-config=SC1 with syncURL pointing to local://@C2, with > Xmn source=S1a+uri=S2a<@C2 implied>, source=S1b+uri=S2b<@C2 implied> > > "server": context=C2, source=S2a of type contacts, S2b of type events, > sync-config=target-config with an irrelevant syncURL > > I could --sync SC1@C1, and this would cause S1a and S2a to be synced, > and S1b and S2b to be synced Correct, except that client and server need to be swapped again. I am not sure how much it helps to explain local sync in terms of SyncML. It helped Graham, but one either has to be intentionally imprecise (swap client and server) or explain about server initiated SyncML syncs. -- 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
