[adding the list back - Emile, please remember to do a group-reply] On Wed, 2014-04-09 at 19:46 +0200, Emiliano Heyns wrote: > On Apr 9, 2014 5:52 PM, "Patrick Ohly" <[email protected]> wrote: > > > > So the target-config is considered to live inside the data source? > > > > Not inside the data source. It's treated like a sync config and thus > > lives inside a context. Like a normal sync config it is connected to > > data source configs via that context. > > So target configs can potentially be applied to any data source with > which it shares a context.
There is only one "target-config" per context, because the name is (currently) fixed. As discussed with Graham, this limitation could be removed in favor of letting users choose their own target config name with syncURL=local://<target config>@<context. > > > And if the > > > target-config hosts the sync property, it's also (in addition to > being a > > > kind of sync config) a kind of source config it seems. Which > properties > > > can a target-config hold? > > > > A target-config is exactly like a sync config and can hold all of > the > > sync properties. Whether all of them are useful or valid is a > different > > question. It's the usage that determines the difference between a > sync > > and a target config. > > 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". 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. 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. Perhaps this becomes clearer when you look at the config.ini files created under ~/.config/syncevolution. This shows you all existing sets of config properties (source vs. sync, per-peer vs. shared). The original config mechanism didn't have shared properties or contexts. This made it impossible to define a source independently of a sync config for a peer. This was replaced with today's system without changing the command line. The command line creates a flat view of all relevant properties (when printing a config) and updates the relevant config.ini file for each property (when modifying). This is a two-edged sword. Users who only have one sync config can configure it as easily as before, without having to deal with multiple different invocations for the different entities involved. But anyone trying to do advanced things (and local sync with multiple different databases is advanced) needs to understand the underlying logic, or follow recipes. Ideally this complexity would be hidden by some kind of UI with a setup wizard. But no-one has volunteered to write that for desktop Linux or even update the existing GTK UI, so desktop users are stuck with the command line. > > > If I were two sync two paired sources, that would allow for 4 > places > > > where a sync property could be set then? What are sensible > combinations? > > > > In a local sync, sync properties can be set in two places: on the > side > > used to trigger the sync (called "local" in the sync output) and the > > target side (called "remote"). > > I'm talking specifically about the property called 'sync'. Does it > live in the data source (which was my first guess as it is listed as a > source property) or in the target/sync config? Or both? And what is > the expected behavior if two sides of a sync specify different values > for the 'sync' property? On the target side of a local sync the "sync" property is ignored. The sync side chooses the sync mode and enables the corresponding target sources automatically, without the user having to set their "sync" property. -- 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
