Re: [SyncEvolution] Getting the concepts clear (Was: Configuring a target)
On Thu, 2014-04-17 at 10:02 +0000, Emiliano Heyns wrote:
On 17/04/2014 11:54:18, "Patrick Ohly"
<patrick.ohly(a)intel.com> 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.