Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On 10/04/2014 01:20:27, "Graham Cobb" <g+syncevolution(a)cobb.uk.net>
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