On 10/04/2014 01:20:27, "Graham Cobb" <[email protected]>
wrote:
The "sync" property is a per-peer source property. It defines how a
data
source is used by a specific peer. Therefore it makes no sense to
"--configure sync=two-way @default addressbook", because there is no
peer mentioned anywhere and this "sync" value cannot be stored. The
"addressbook" source config referenced here only has the shared
source
properties, which do not include "sync".
It is this concept which I have found hard to grasp. I think part of my
problem is that there is no "object" on which to hang these "per-peer
source" properties.
*This*. I've been bashing my head against exactly this.
I think a diagram (or even a UML description) would help. In the
absence of a diagram, let me see if I have grasped this...
Imagine a context (call it @Ctx) which contains three sources (S1, S2,
S3)
Why would these not be named S1@Ctx, in keeping with how you name the
peers/sync configs? S1 can't exist separate from its hosting context,
and it can't live in more than one.
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.
| S1 | S2 | S3 |
---+----+----+----+----
P1 | X11| X12| X13|P1 sync config properties
---+----+----+----+----
P2 | X21| X22| X23|P2 sync config properties
---+----+----+----+----
|S1 |S2 |S3 |
|shrd|shrd|shrd|
|prop|prop|prop|
If this is correct, this is an enormously helpful visualization. If you
would be able to add the target-config to it, that would make the
picture complete for me.
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
