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. 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
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
