On Thu, 2014-04-17 at 18:39 +0000, Heyns Emiliano wrote:
> ------ 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.
... about a peer. For example, syncURL or remoteDeviceID must be set to
something identifying the peer, otherwise GNOME keyring can't be used.
It's not required otherwise, but the intention is the same. This is
information about how to log into a peer, the same information that is
also stored in other peer configs.
> 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". 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.
> >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.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
