On Thu, 2014-04-17 at 10:02 +0000, Emiliano Heyns wrote:
> On 17/04/2014 11:54:18, "Patrick Ohly" <[email protected]> wrote:
>
> >On Thu, 2014-04-17 at 07:50 +0200, Emiliano Heyns wrote:
> >> With regards to "sync config", can a sync config always figure as
> >> either a client-peer or a server-peer, depending only on how it's
> >> used, not how it's configured?
> >
> >I'm not sure I fully understand the question. Do you mean, "can
> >SyncEvolution figure out whether a sync config is for a client or
> >server"?
> No, I mean: can a sync config appear both as a client or as a server
> without any change to its properties?
The target config might be (mis)used like that: set
syncURL=bt-obex://... and sync with it -> it acts as SyncML server.
Point to it elsewhere with syncURL=local:// -> it acts as SyncML client
with a different peer.
This is a special case, though, and not intended. In general, a sync
config has exactly one role.
> If so, "what it is" is ambiguous
> until it's used. If it is not ambiguous until it's used, it implements
> storage for an identifiable class of objects, which do different things
> (clients and servers do different things), so should be named
> differently.
One can have a hierarchy of terms:
peer config
/ | | \
/ | | \
SyncML client config | | SyncML server config
| |
| target config
originating config
I'm using "client/server config" here to illustrate the point. I'd
prefer to not introduce them because of the ambiguity.
I am not convinced that we really need separate terms for SyncML sync
configs. "sync config" works for me, with originating and target config
as special cases of that.
> >I remember that it was difficult in the past to talk about the client
> >config or server config because it is ambiguous whether the client
> >config is a configuration *on* the client or on the server *for* the
> >client.
> >
> >Using the neutral "peer config" might avoid that.
> Which is why I'd want to separate concepts like "peer" (a 'class', if
> you will), from "peer config" (an instance)
Agreed. "peer" remains as defined before (some entity to sync with), and
"peer config" is what SyncEvolution uses to achieve that.
--
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
