On Mar 9, 2012, at 14:30 , Patrick Ohly wrote:
On Tue, 2012-03-06 at 14:50 +0100, Patrick Ohly wrote:
> I haven't look into this yet, but still have it on my radar.
Done in the meego.gitorious.org
master branch. I found that checking for
collisions is hard (not all records are in memory), so I settled for
making the chance of collisions smaller in the string case by including
a running count.
I guess this is way safe enough.
The worst that can happen is that two (at that time by definition already obsolete) server
items will get a mapping to the same client ID when a fake-ID generation collision should
occur (which now can only happen with suspend&resume where libsynthesis is
reinstantiated in between).
If so, the client will send two deletes for the same clientID to the server in a
Depending on the server implementation, either the first delete wipes all items mapped to
that ID and the second delete will get a 404, which is fine. Or the first delete wipes
just the first item that maps to that item, and the second delete then wipes the second -
correct as well.
Even if a super-smart server would merge the two items upon receiving a map to the same
clientID, the end result would be correct (altough the merged item would likely make no
sense - but as it is doomed at the time of merge already that would be an acceptable
intermediate state for a case that is extremely unlikely to occur at all).
Lukas Zeller, plan44.ch
luz(a)plan44.ch - www.plan44.ch