On Fri, Jul 1, 2011 at 16:54, Dov Feldstern <dovdevel at gmail.com> wrote: > On Fri, Jul 1, 2011 at 16:29, Neal H. Walfield <neal at walfield.org> wrote: >> At Fri, 1 Jul 2011 15:35:52 +0300, >> Dov Feldstern wrote: >>> 3. n900 at 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 > Thinking about this a bit more, I think that using server-based action-upload times would also solve / obviate the need for solving https://bugs.gpodder.org/show_bug.cgi?id=1366 .