Hi Patrick, 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 subsequent sync. 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). Best Regards, Lukas Lukas Zeller, plan44.ch l...@plan44.ch - www.plan44.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
