On Thu, 2014-04-10 at 00:20 +0100, Graham Cobb wrote: > 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?
Yes. > 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). I'm open for suggestions. But beware that it doesn't stop there. There are also two other kinds of sync properties: "global" and "shared". A "global" property has exactly one value that is used everywhere. It gets treated by the command line like a sync property because it didn't seem worthwhile to introduce a new category for something that is used very rarely. Of the two such properties, one is only relevant for the UI: defaultPeer (no default, global) keyring (yes, global) The "shared" sync properties are shared by all sync configs inside the same context. In other words, these are properties of the context. In the diagram above that would be the empty box at the bottom right corner. Once again you guys are mercilessly revealing how much I already forgot about SyncEvolution ;-) When I said to Emile that a context can always be created indirectly because it has no properties of its own, I forgot about the following ones. OTOH, SyncEvolution works fine when they are not set explicitly, using defaults built into the engine (they are listed as "not default" only because the config system has no default value and reports them as empty). logdir (no default, shared) maxlogdirs (10, shared) deviceId (no default, shared) As with some of the other properties, where to put them is a somewhat arbitrary decision based on the tradeoff between "how useful is it to allow separate values for different syncs vs. how cumbersome it would be to set a non-default value repeatedly". deviceId is used to identify the client or server in a SyncML sync. At first glance a global property might make more sense; it's attached to a context instead because then different contexts can be used to simulate different clients. > > 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)? That's a different way of looking at it. But it's not the one used in SyncEvolution. In SyncEvolution, the viewpoint is from the individual sync config as the starting point, and from that view there is one "sync" value per source. > 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. Can't argue with that. As I said, I'd be happy to discuss a revised command line that discards these confusing aspects. > [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? Correct. However, apparently I forgot to implement a specific check for this kind of error. Instead the extra property value is silently ignored (I just checked). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
