5:19 a.m.
On 10/04/2014 21:03:05, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
On Thu, 2014-04-10 at 15:31 +0000, Emiliano Heyns wrote:
> On 10/04/2014 12:11:34, "Patrick Ohly" <patrick.ohly(a)intel.com>
>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.
A
peer can have multiple sync configs, and a peer loosely translates to a
device or service or other syncml instance, but is merely a notational
convention to mentally cluster several sync configs. Correct?
> >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?
> >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. But then (currently) the
target-config cannot hold one either, as it's just a "special sync
config"; I've updated the schema to show that simply exactly one of the
Context's sync config can special in that it is considered its
target-config.
> My data visualizing skills are non-existent, so I've
resorted to the
> only tool I know in this domain: SQL. Could you guys have a look at
> http://reichenhack.github.io/syncevolution-model.html to see if this
>is
> going somewhere?
"forceSyncFormat, sync, syncFormat, uri" are not placed correctly in
that model at the moment. Other than that this looks right.
Updated.
Regards,
Emile