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. Bye, Patrick Am 18.04.2014 22:06 schrieb "Heyns Emiliano" <[email protected] >: > ------ Original Message ------ > From: "Patrick Ohly" <[email protected]> > To: "Heyns Emiliano" <[email protected]> > Cc: "Todd Wilson" <[email protected]>; "Graham Cobb" < > [email protected]>; "SyncEvolution" < > [email protected]>; "Ove Kåven" <[email protected]> > Sent: 18-4-2014 21:37:50 > Subject: Re: Re[2]: 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 to". >> 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 > non-generic. > >> >> >> >As said in the other mail, that does not rule out using more specific >>> >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. >> > 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 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. > > Regards, > Emile > >
_______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
