[gpodder-devel] my.gpodder episode sync design problem: "since" values
- From: dovdevel at gmail.com (Dov Feldstern)
- Date: Fri, 1 Jul 2011 15:35:52 +0300
Hi!
I'm still seeing occasional episode actions which are not getting
synced correctly between my n900 and my desktop, and I've finally
uncovered another cause of this; however, this seems to be a design
issue, which will require some discussion for solving...
Some background:
* Episode sync actions have a "timestamp", which is the time at which
the action occurred.
* When syncing with my.gpodder.net, a client receives from the server
a timestamp, which it can use next time in order to only ask for
actions which are newer than the last sync; this timestamp is the
"since" value.
The problem occurs when one of the clients (say, the n900) is not
connected to the net:
1. n900 at 9:14 : finish playing episode, an action is stored with timestamp
"9:14"
2. desktop at 9:16 : start gpodder, this causes a sync, new since value is
"9:16"
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...
Note that the problem can actually occur even if both clients are
always connected: actions are actually not uploaded to the net
immediately, but rather are stored locally, and a worker thread which
runs every now and then uploads the stored actions to the net. So two
clients which are connected simultaneously may have worker threads
which are out of sync, and then the following timeline could happen:
1. Client A at 9:14 : episode action stored, timestamp "9:14", but not uploaded
2. Client B at 9:16 : worker thread wakes up, syncs, new since value is "9:16"
3. Client A at 9:18 : worker thread wakes up, syncs, action from step (1)
uploaded with timestamp of "9:14", and we're in the same situation
again, even though everyone was connected throughout...
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. Note that this would
not require any changes in the protocol, because only the server needs
to know about the upload timestamps. However, clients need to be aware
that they may receive actions with a timestamp earlier than the since
value they provide when syncing (I don't know if they currently make
any assumptions about this or not).
How does this sound? (I didn't open an issue for this yet, because I
wasn't sure against which component to do it; though now that I've
written it up, I'm pretty sure this can be solved with changes only to
the server; however, I might as well hear what others have to say
before opening a bug report...)
Thanks!
Dov
Other related posts:
