I don't think we have consensus on the revised terminology. My updated
readme will need further changes.
At this point I'd like to get feedback from others before proceeding.
Graham, Ove, Todd?
It's now Eastern, and I'll be away for a few days myself. Let's not hurry.
Am 18.04.2014 22:06 schrieb "Heyns Emiliano" <emiliano.heyns(a)iris-advies.com
------ 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" <
g+syncevolution(a)cobb.uk.net>; "SyncEvolution" <
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 peer,
>> it just holds referencable properties.
> ... about a peer.
Which makes it "not a peer". I am not my drivers' license.
> 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 else)".
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
> This is relevant for the part of SyncEvolution that needs to be generic.
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 appropriately
> >As said in the other mail, that does not rule out using more specific
>> >terms where applicable ("a target config is a special peer
>> But is there a scenario where the 'peers' in a sync are indeed 'at
>> 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.
Fine, 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 for
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.