With regards to "sync config", can a sync config always figure as either a client-peer or a server-peer, depending only on how it's used, not how it's configured? Then I'd say that "peer" *is* an apt description of what it does, and the documentation must then explain in context when it's used as a client-peer or a server-peer. As this peer can not sync without the Xmn entries, calling *those* the sync configs of the peer would make sense.
If a sync config (in its current incarnation) is instead always inherently a server-peer or client-peer, then those are meaningful concepts for syncevolution, and I'd propose that they'd be introduced as first-class concepts, regardless of whether they might share an implementation in code. Emile On Apr 16, 2014 9:31 PM, "Patrick Ohly" <[email protected]> wrote: > 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
