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