------ Original Message ------
From: "Patrick Ohly" <patrick.ohly(a)intel.com>
To: "Heyns Emiliano" <emiliano.heyns(a)iris-advies.com>
Cc: "Todd Wilson" <twilson(a)csufresno.edu>; "Graham Cobb"
<syncevolution(a)syncevolution.org>; "Ove Kåven" <ovek(a)arcticnet.no>
Sent: 18-4-2014 21:37:50
Subject: Re: Re: documentation update, enhanced command line
> I disagree, I really do. For starters, number 4 doesn't describe a
> it just holds referencable properties.
... about a peer.
Which makes it "not a peer". I am not my drivers'
> They are only peers in the sense that they are
> paired, but they're in no sense equals, or "something that is, at a
> level equal (to that of something else)".
So your concern is that "peer" implies "equals".
"peer" doesn't imply equals, it means equals; from wiktionary, for
example: "something that is, at a level equal (to that of something
I chose that term
intentionally because I wanted to have a word that includes both client
and server. Instead of saying "the client or server that SyncEvolution
talks to" I wanted to say just "the peer that SyncEvolution talks to".
This is relevant for the part of SyncEvolution that needs to be
So the word peer is then entirely appropriate there. If there is indeed
a place where you want to say "client or server, doesn't matter which",
then for the scope of that discussion, these are indeed equals. But
anywhere where you want to talk about clients or servers, even if they
figure as true peers elsewhere, these are not peers. There are parts
where the explanation of what SyncEvolution does and how it does it is
> >As said in the other mail, that does not rule out using more
> >terms where applicable ("a target config is a special peer config").
> But is there a scenario where the 'peers' in a sync are indeed 'at a
> level equal'?
That's not the point. In a particular application of the generic
concepts in SyncEvolution (for example, in a HOWTO) it makes sense to
use more specific terms. In the README.rst where the command line
options for setting up a "peer config" are described it doesn't.
I'll accede that point. That describes a general mechanism for
setting up "things that figure in a paired set that are to be synched"
(and for the scope of that description, they are equals), for which the
configuration commands happen to be alike. But at some point anyone who
wants to use SyncEvolution will want to set up specific kinds of things
that happen to be configurable by setting up a peer config in a specific
way. I haven't seen any example so far that sets up a peer for actual
use that doesn't have a very specific role (and the ones I've found so
far are 'client', 'server' and perhaps that 'bag of properties ready
use' kind), and knowing and being able to name this purpose is very
important for making understandable documentation.
I don't think this debate is leading us somewhere fruitful, however.
I'll keep with the 'peer' terminology, which I think is already a step
above 'sync config'. I think the use of the term peer for something like
candidate #4 (the bag of referencable properties) where that does not
represent an actant is a category mistake, but I'm not going to push
that point any further, and focus on getting something out that is
useful for the starting user, uses terminology from the updated
README.rst you mailed where possible, and will nowhere contradict it.