------ Original Message ------
From: "Patrick Ohly" <[email protected]>
To: "Emiliano Heyns" <[email protected]>
Cc: "Ove Kåven" <[email protected]>; "SyncEvolution"
<[email protected]>
Sent: 16-4-2014 21:30:58
Subject: Re: [SyncEvolution] Getting the concepts clear (Was:
Configuring a target)
Hello!
It's getting more accurate, but it's still not 100% there.
On Wed, 2014-04-16 at 08:12 +0000, Emiliano Heyns wrote:
On 15/04/2014 12:14:15, "Patrick Ohly" <[email protected]>
wrote:
The target-config specifies a faux syncml server,
It's more like a client in a server-initiated sync.
So the 'sync config' the target-config is talking to is considered the
server, and it is this server that initiates the sync. And it's called a
target-config because this server 'points itself' at this target to
initiate sync.
which (conceptually) awaits the incoming connection. This incoming
server must know what data stores it has available; this is
registered
in its Xmn entries,
"it" and "its" is ambiguous. I think you mean the right thing: "This
incoming server must know what data stores the target config has
available; this is registered in the incoming server's Xmn entries".
The newer text already clarifies this somewhat. The updated text, which
still has the apparently false concept of the faux server, lives at
http://reichenhack.github.io/syncevolution.html ; it is a lot more
structured than the message I posted earlier, which was mostly to see
whether I had gotten the concepts roughly correct. The document is
mostly written out, a lot more structured, and includes examples.
The SyncML client chooses which sources it wants to sync with. This
is
what SyncEvolution as SyncML client does via the "uri" property,
"client" has to be "server" here if you want to be technically correct,
and consistent with the user-visible "peerIsClient" property.
This has also been updated in the document at the URL I mentioned for
sure. That document still swaps around the server and client ends, I'll
try to get that corrected later tonight.
Correct, except that client and server need to be swapped again.
I am not sure how much it helps to explain local sync in terms of
SyncML. It helped Graham, but one either has to be intentionally
imprecise (swap client and server) or explain about server initiated
SyncML syncs.
This certainly is an interesting point. My document intends to explain
to an end-user what is going on, conceptually, referring to the
artifacts of implementation only where necessary. If the swapped
terminology is conceptually correct (unlikely, but not impossible), I
would not see that as problematic; I do not intend these documents to be
100% technically accurate, but 100% useful. But it cannot conflict with
the technical implementation to the point that it becomes a "leaky
abstraction", because that is guaranteed to bring new confusion down the
line.
So it sounds to me like server initiated syncs will have to be part of
the explanation. If a server initiated sync is conceptually different
from:
Server: Let's see if I can find Client... Oy, Client! I have contacts
and memos for you!
Client: Bring it!
Server: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Client: OK, got that. Bye!
Server: You still here?
then I'd appreciate it if you could point me to some reading that
explains it. Simple preferred, technical OK.
Regards,
Emile
_______________________________________________
SyncEvolution mailing list
[email protected]
https://lists.syncevolution.org/mailman/listinfo/syncevolution
