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? 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.
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.
So it sounds to me there are clearly separate roles at play here.
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.
Which is why I'd want to separate concepts like "peer" (a 'class', if
you will), from "peer config" (an instance)
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
