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