On 13/04/14 19:45, Heyns Emiliano wrote:
> On a different tack, I am slowly starting to figure out what the various
> command line calls mean in the HOWTOs that are available, and the
> scripts that I've assembled, but this one still eludes me:
>
> syncevolution --configure sync=two-way uri=calendar Exchange@Local calendar
>
> From what I can gather, this sets the properties on Xmn entries (because
> only Xmn have these properties). But Exchange and Local are contexts;
> the synopsis says this is a 'config', which I take to be a Sync Config
> (which I've dubbed 'Peer' above), so I could imagine it'd set these
> properties on an Xmn described by either m = <some peer inside Exchange>
> or <some peer inside Local> and n = 'calendar' (a source in either
> Exchange or Local), but I don't understand how SE figures out which peer
> in which context, and how it figures out which context it should choose
> source 'calendar' from.
That is my fault, for causing confusion. Although @Exchange is, indeed,
a context, the name "Exchange" is not being used to mean that in this
command. "Exchange" is, in this case, also the name I used for the peer
config within the @Local context. Two different entities (of different
types) with similar names. And completely unrelated as far as SE is
concerned (they get linked later by using the local:// url).
But I always think of the peer config as pointing to the peer. So, in
my mind, I tend to name the peer config in one context with the same
name as the context name it will eventually link to. But I probably
shouldn't have done that in the example, to avoid confusion.
It might be useful to always include the @ at the front of names of
contexts, to reduce this confusion. There is nowhere in the command
line where the context name ("Local") can appear without the @ in front
-- so you may as well consider the @ part of the name.
Graham
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
