On Thu, 2014-04-10 at 15:44 +0000, Emiliano Heyns wrote: > 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.
True. See ~/.config/syncevolution/config.ini. > >> 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. Correct. There are multiple ways of describing it and there isn't necessarily one which is more correct than the other. However, for SyncEvolution there never really was a choice: the terms "source", "source config", "sync config" come from the Funabol engine that SyncEvolution was orginally based on. In the beginning there were no shared properties, so one had to configure a source again and again for each peer. Operations on sources without a peer were not possible. > >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. Fair enough. However, when or if changes to the model are proposed, then the implications for user documentation and the command line syntax should also be considered. -- 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
