------ Original Message ------
From: "Patrick Ohly" <patrick.ohly(a)intel.com>
To: "Emiliano Heyns" <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: 17-4-2014 16:42:37
Subject: Re: documentation update, enhanced command line
On Thu, 2014-04-17 at 09:58 +0000, Emiliano Heyns wrote:
> On 17/04/2014 11:01:24, "Patrick Ohly" <patrick.ohly(a)intel.com>
>wrote:
>
> > I am entirely open to ditching client endpoints. I feel iffy about
> >'sync
> >> config' because it is so generic; it doesn't really disclose
>anything
> >> except 'it does something with sync' -- but then, everything of
> >> syncevolution does something with sync.
> >
> >"sync config" has to be fairly generic, because sync configs are
>used
> >for all kinds of things:
> > * Syncing with SyncML clients.
> > * Syncing with SyncML clients.
> > * The two sides in a local sync.
> > * To store username/password once for several other sync or
> >source
> > configs (see "id:<name of config with credentials>" in the
NEWS
> > file).
> But that's the thing. So we have 4 (I guess... one of the first two
> would be "server" yeah?)
Yes, a typo.
> entirely different concepts,
I wouldn't call these entirely different concepts. They all provide
information about a peer, so "peer config" looks like suitable generic
term.
I disagree, I really do. For starters, number 4 doesn't describe a peer,
it just holds referencable properties. A peer might use these, but also
a store, and there's nothing number 4 is paired with where they're
conceptual equals; instead, there is a very strict use-relation between
the bag-of-properties and the user-of-the-bag-of-properties. I am not a
peer with the knives in my kitchen.
The first two might both describe a peer, but these are very different
kind of peers; "nginx" and "chrome" are peers in a web-browsing
session,
but if you'd have to describe a HTTP exchange in terms of "the peer
sends a HTTP GET request to the other peer, who responds by sending back
a success or fault response code to the first peer", this would not be
meaningful to someone who doesn't already know that "the peer" is a
server-peer, and "the other peer" is a client-peer, and that switching
them around would simply not work; the wording implies a same-ness that
simply isn't there. 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)".
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'? Perhaps the "two sides in a local sync"; I'd have to go
find out what a "local sync" means other than "a client-server sync with
the network bits short-cut".
> >I'm fine with introducing a separate term for this, but
it needs to
>be
> >something that fits. My own best idea was and still is "per-peer
>store
> >properties".
> I'm fine with that. Are these used for anything but a sync though?
No, not at the moment. I just don't find "sync config" suitable due to
the legacy usage of that term.
That I understand, and I do not contest. Re-use for a different meaning
would only make matters worse.
Regards,
Emile