On Fri, Jul 1, 2011 at 16:29, Neal H. Walfield <[email protected]> wrote: > At Fri, 1 Jul 2011 15:35:52 +0300, > Dov Feldstern wrote: >> 3. n900@9:18 : connects to network, stored actions are uploaded; so >> the action from step (1) is now uploaded, *but its timestamp is still >> "9:14"*! Since "9:14" is earlier than the new "since" value ("9:16"), >> the episode action will never get synced back to the desktop... > >> So, I think that the "timestamp" stored with actions is *not* the >> value which should be used for purposes of comparing with "since" >> values and syncing; rather, an "upload-timestamp" should be stored >> server-side, which would serve for this purpose. > > Why not use Lamport timestamps to do the ordering? > > http://en.wikipedia.org/wiki/Lamport_timestamps > > Neal
Hmmm, first of all, because I was not familiar with Lamport timestamps ;) . However, after skimming over the article, I think they solve a different problem than the one we're facing. In our case, there's a single point of reference (the server), so we really don't have a problem of ordering events -- we can *know* the *exact* order in which the events happen on the server, which is what's important for syncing. Our problem is that there are really two different events happening (the actions themselves, and the actions upload) at two different times (action-time, upload-time). For sync purposes, only the upload-time is interesting; however, we're confusing the two times, and using action-times for dync purposes, which is what's causing the problem. So, I don't really think that Lamport timestamps can help us out here, though they may be useful if some kind of client-to-client synchronization, which does not go through a central server, is ever implemented... Thanks! Dov _______________________________________________ gpodder-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-devel
