On Fr, 2010-02-26 at 15:12 +0000, 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 [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
