On 10/04/2014 11:57:24, "Patrick Ohly" <[email protected]> wrote:
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)
So these live outside any context.
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)
OK, I've taken these into account in my SQL 'model'
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.
OK, so deviceID is a property used for sync, but hosted in the context.
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.
But if you look at it from the perspective of the data source, exactly
the same reasoning would hold. This indicates that, no matter how it is
commonly spoken of, this is a matrix in which these values live. The way
it's used from any particular (limited) perspective does not describe in
full what this X is. I've added that to my SQL schema as a separate
entity 'SyncMode'.
Can't argue with that. As I said, I'd be happy to discuss a revised
command line that discards these confusing aspects.
The command line is of later worry, I think. This kind of clarification
that is happening here must precede it. The command line can probably
stay as is, and it's behavior be regarded as having some idiosyncrasies
against and otherwise coherent conceptual model.
Regards,
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
