9:20 a.m.
On 09/04/14 21:39, Patrick Ohly wrote:
> But it can apparently also hold a property named 'sync',
and that's
> listed as a source property. I'm confused now about what happens when
> you set the 'sync' property. Is the target-config changed? Then
'sync'
> appears to be a sync property. Is the source config changed? Then
> what's the role of the sync config being passed on the command line?
> The wording seems to imply something happens to the target-config when
> setting the 'sync' property, but that conflicts with how you spoke
> about what sync and source configs can hold.
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.
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) and two sync configs representing peers (P1@Ctx, P2@Ctx). Then
there are a a bunch of objects as in this matrix:
| 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|
Where Xnm presents the "non-shared" (=== "per-peer") source
properties
of Sm for sync config (===peer) Pn.
The property called "sync" is a "non-shared source property", so it is
a
property of each of the objects called Xnm in my matrix.
Is that right?
If so, I think the terminology description needs to be updated to define
these Xnm objects as first-class objects and give them a name. After
all, they are the objects of which the "non-shared source properties"
are properties. And then there are three types of properties:
properties of the three types of objects (Pn, Sm, Xnm).
The "sync" property is primarily a source property, because
in contrast
to sync properties there are multiple values for it, one for each
source. You can also think of it as the "sync" aspect of a data source,
when describing the role of a source in a sync.
I don't see how that makes sync "primarily" a source property. Doesn't
exactly the same logic make it primarily a sync property as there are
multiple values for it, one for each peer (isn't that what per-peer
means)? The truth seems to be that it is a matrix property with values
that are per-source-peer-combination, and pretending they are some
special sort of source property just causes confusion.
[I have re-ordered Patrick's email here]
Following that logic, the "--configure sync=two-way
memotoo@default
addressbook" operation becomes valid and sets the "sync" property of
"addressbook" for syncing with memotoo.
OK, that makes sense. This is setting a property of one of my Xnm objects.
So, what happens when I specify "--configure sync=two-way
memotoo@default"? Is that an error (because sync is not a property of
my Pn objects)? Just like "--configure sync=two-way @default
addressbook" is an error because sync is not a property of my Sm objects?