On Wed, 2014-04-09 at 13:20 +0000, Emiliano Heyns wrote: > OK, so let me see if I have got it now: > > 1. A config is a typed bundle of properties. It is either a sync config > or a source config. Which of these two it is depends on its position on > the command line on first use, but it cannot be changed after creation > 2. In any given invocation, syncevolution decides what properties go to > the source or sync config(s) on the command line based on whether they > "belong" to one type or the other. Naming ambiguities can be overruled > by specifying --(source|sync)-property, but the current names are > distinct so there is no practical need to do so right now. > 3. Properties provided during invocation that do not have a > corresponding config kind provided are silently ignored
There might be error checks which trigger when a property can't be set because it does not match what's currently getting configured. Sorry for saying otherwise earlier, sometimes I don't remember the exact behavior in error cases myself. > >> In the synopsys, target-config is being explained in terms of being a > >> special kind of sync config, But when configuring it, I can pass it a > >> sync= parameter, where the sync property is a source property, not a > >> sync property. How should I see this? > > > >The "sync" property will get set for "target-config" in the sources > >named together with the target-config. > 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. > 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. > 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"). syncURL has to be set in a specific way on the local side. It gets ignored on the target side. loglevel is perhaps the most important property where it makes sense to use different values on both sides, depending on what gets debugged. printChanges makes more sense on the local side. -- 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
