On Thu, 2014-04-10 at 19:19 +0000, Emiliano Heyns wrote:
> On 10/04/2014 21:03:05, "Patrick Ohly" <[email protected]> wrote:
>
> >On Thu, 2014-04-10 at 15:31 +0000, Emiliano Heyns wrote:
> >> On 10/04/2014 12:11:34, "Patrick Ohly" <[email protected]>
> >>wrote:
> >>
> >> >> >and two sync configs representing peers (P1@Ctx, P2@Ctx). Then
> >> >> >there are a a bunch of objects as in this matrix:
> >> >> In which, just to see if I understand this correctly, P1@Ctx
> >> >>describes
> >> >> how peer P1 can access S1/2/3.
> >> >
> >> >The full line for P1@Ctx describes how P1 syncs:
> >> P1 here is a peer then, and P1@Ctx (aka a sync config) describes
> >>within
> >> Ctx exhaustively how P1 can sync in Ctx? Or could a single peer
> >> (sensibly) have multiple of these within a single context?
> >
> >Both works for syncs initiated by the user of SyncEvolution. When
> >SyncEvolution acts as SyncML server, the protocol forces us to have a
> >single sync config for the SyncML client with all sources enabled that
> >it is meant to have access to.
> >
> >Apart from that there's nothing wrong with having different sync
> >configs
> >for the same peer, whether it is in the same context or in different
> >ones. The original goal was to have just one sync config (say, "google"
> >instead of "google-contacts" and "google-calendar") because it allows a
> >single command to sync all data of that peer ("syncevolution google"
> >vs.
> >"syncevolution google-contacts && syncevolution google-calendar");
> >ultimately that's up to the user.
>
> OK, given this then, "peer" and "sync config" are different concepts.
Correct, and the terminology section describes them as different things,
too.
> A
> peer can have multiple sync configs, and a peer loosely translates to a
> device or service or other syncml instance,
Correct.
> but is merely a notational
> convention to mentally cluster several sync configs. Correct?
I wouldn't describe it like that. A peer typically really exists in the
physical world, so it is more than just an abstract convention.
> >> >the Xmn boxes describe
> >> >how it access the respective source (basically the "sync" mode) and
> >>the
> >> >last column has the sync properties for the peer.
> >>
> >> So: P1@Ctx has sync config properties that describe all relevant sync
> >> properties for the peer except the sync mode of that peer with any
> >> single data source within that context, which is held by the Xmn
> >>entity.
> >> If so, for the sake of current discussion, I would propose to call
> >>that
> >> SyncMode.
> >
> >"uri", "syncFormat" and "forceSyncFormat" also fall into the same
> >category. Calling them "SyncMode" isn't really appropriate.
> >
> OK, I've moved them and simply renamed that entity to SyncSource for
> now. The 'sync' property is currently located on the DataSource -- that
> is still correct?
No. What you had is "mode" in "SyncMode" is the "sync" property value.
> >> >From the perspective of the configuration system, "target-config" is
> >> >just another sync config and thus another line in the diagram.
> >>Nothing
> >> >stops you from setting a "sync" property in one of the Xmn boxes.
> >>But
> >> >these values are not used and therefore don't make sense there.
> >>Perhaps
> >> >this can be visualized like this:
> >> >
> >> But above you said that Xmn specifically holds the "sync" mode. Is
> >>this
> >> different from the "sync" property?
> >
> >No, it's the same thing. With sync mode I meant the value of the "sync"
> >property: one-way, two-way, etc.
> So this 'sync' property is then not part of Xmn (which I dubbed
> SyncSource for now), but of the data source.
The "sync" property lives in the intersection of data source and sync
source, so it *is* part of Xmn. I would even say that it is the most
important part of it, although there are others ("uri", "syncFormat" and
"forceSyncFormat").
--
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
