On Fr, 2010-02-26 at 15:12 +, Patrick Ohly wrote:
Hello!
When we started with SyncEvolution, we discussed the StartDataRead()
resumeToken parameter. At that time, we came to the conclusion that a
binfile based client doesn't have to distinguish between different
tokens. Always reporting the changes since the last sync is good enough,
the binfile layer takes care of merging the recent changes with those
that haven't been sent.
Now, on the server side I think tokens are relevant, right?
SyncEvolution as server doesn't support multiple tokens yet, and I was
hoping that one of the existing tests would fail because of that, but no
luck so far. I found two problems (see other emails), but none that I
could attribute to SyncEvolution ;-}
In which situation on the server side is the distinction between
lastToken and resumeToken relevant?
I discussed this with Lukas. Here's my write up of the answer:
http://bugzilla.moblin.org/show_bug.cgi?id=2425#c5
(In reply to comment #4)
True. However, I learned in the meantime that the binfile support is not
enabled for SyncML servers. Once we turn SyncEvolution also into a server,
we
need to revisit this issue.
... so now we need to solve this issue. Without it, our suspend/resume tests
against our own server should fail.
Only in some very constructed situation, and one which is not currently covered
by any of our tests. Here's where the two anchors make a difference:
1. client and server in sync
2. item added on server
3. client and server sync
4. suspend after sending that new item to client
5. a second item added on server
5.1 resume = send changes since step 4
5.2 two-way sync instead of resume,
using anchors from step 1 = send changes since
step 1
Our server fails in 5.2, because it will always only send changes since the
last sync (step 4 in this example).
The relevance of this is debatable. It depends on clients actually being able
to roll back to a previous state. Our own client can't do that, so it would
have to do a slow sync in 5.2 instead of resuming.
--
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.
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
