------ Original Message ------
From: "Patrick Ohly" <[email protected]>
To: "Emiliano Heyns" <[email protected]>
Cc: "Todd Wilson" <[email protected]>; "Graham Cobb"
<[email protected]>; "SyncEvolution"
<[email protected]>; "Ove Kåven" <[email protected]>
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" <[email protected]>
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
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
