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.
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").
> >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.
--
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
