Conceptually, a server and a client are very different. But I'm not even looking for sync configs to get different names (even though "peer" would be more descriptive than "sync config"), but the roles these entities can play. And for certain the last of the four is conceptually entirely different; it doesn't configure a sync at all, it is referenced by a peer which may or may not be present in a peer-pairing.
Emile On Apr 17, 2014 4:42 PM, "Patrick Ohly" <[email protected]> wrote: > 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
