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, not at the moment. This has to be configured explicitly via
peerIsClient.
Perhaps this can be changed, by making an educated guess based on the
syncURL.
Case 1: SyncEvolution as HTTP SyncML client. Do this if
syncURL=http[s]://.
Case 2: SyncEvolution as HTTP SyncML server. Config is found via device
ID in first SyncML message, then acts as server.
Case 3: SyncEvolution as Bluetooth server (via obexd plugin): first
message is SyncML, same handling as for HTTP => act as server. First
message is server-initiated sync message => act as client.
Case 4: SyncEvolution as Bluetooth client. Do this if
syncURL=bt-obex://. Okay, here's the problem. Should SyncEvolution ask
the peer to act as SyncML server or SyncML client? This is determined
based on the peerIsClient value.
Case 5: local sync. Here the roles are currently hard-coded.
peerIsClient has to be set because it might make sense at some point to
reverse the roles without having to swap the configs. A pretty weak
argument IMHO because it will always be possible to swap originating and
target config around, too.
So in essence, if we drop support for one rare case (Bluetooth sync
initiated on a phone as client of a SyncML server on a PC), then
peerIsClient becomes redundant.
In all other cases, peerIsClient has to be set correctly and is (or
should be) tested as a sanity check.
> Then I'd say that "peer" *is* an apt description of what it does, and
> the documentation must then explain in context when it's used as a
> client-peer or a server-peer. As this peer can not sync without the
> Xmn entries, calling *those* the sync configs of the peer would make
> sense.
Hmm, this might work. I need to think a bit more about this.
Feedback from others about the whole discussion would be good.
I am a bit reluctant to reuse an already existing term ("sync config")
for something else, because there will inevitably be a lot of old
documentation that doesn't use it according to the new definition. But
legacy compatibility can't be allowed to hold back progress forever
either.
> If a sync config (in its current incarnation) is instead always
> inherently a server-peer or client-peer, then those are meaningful
> concepts for syncevolution, and I'd propose that they'd be introduced
> as first-class concepts, regardless of whether they might share an
> implementation in code.
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.
--
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
