[gpodder-devel] my.gpodder episode sync design problem: "since" values
- From: koeglstefan at gmail.com (Stefan Kögl)
- Date: Tue, 5 Jul 2011 15:52:32 +0200
On Sun, Jul 3, 2011 at 11:35 PM, Dov Feldstern <dovdevel at gmail.com> wrote:
> So, starting with the single-server situation: I think it is a good
> idea to add a server-timestamp on the server; the server will fill in
> the current time when an action is uploaded; for actions which already
> exist when the change is made, I agree that it is a good idea to use
> the action's timestamp; for existing actions which have no timestamp
> or whose timestamp is in the future, I think I would use the
> current-time.
Sounds good.
> When sending actions to a client who has provided a
> "since" value, the server will compare the since value to the
> server-timestamps. However, the timestamp returned with each action
> will continue to be the user-provided timestamp (though I can't think
> of anything the client should actually be doing with this value --- as
> far as I can see, the only value of this timestamp is for
> presentation/logging --- it is, after all, when the action *really*
> happened).
Clients could generate some history (like the one on gpodder.net) or
figure out where playback stopped last time.
> The "since" values returned by the server will (continue
> to?) be server-based timestamps.
Exactly
> I think the API should be updated to reflect the new usage --- not
> that we're changing the API in any way, but we are changing its
> interpertation. I'm willing to take a stab at this, if you like ---
> can you point me to the sources for the API document? This will also
> help us make sure that we understand each other, and may help to find
> any issues we haven't considered.
The relevant documentation is at
http://wiki.gpodder.org/wiki/Web_Services/API_2#Uploading_episode_actions
> I also think we should go over the client implementations, just to
> make sure that the changes we propose do not break anything. I'm
> willing to look at mygpoclient and gpodder, but I think it would be
> good if someone more familiar with the code also double-checks.
> (Again, basically I think the clients should be ignoring the
> timestamps of received actions altogether.)
I think Thomas will be the one who knows the client source well enough
to judge this.
Thomas, would you mind checking what the implications of the changes
discussed here would be for existing gPodder versions?
> Moving on to the multi-server scenario: I think we need to have a
> better idea (at least than what I have) about what multi-server means:
> in a multi-server scenario, would the servers ever sync up with each
> other? How would that happen? Would a given client always talk with a
> given server, or could it be a different server every time? I think we
> need to be clearer about these details, then we can see what exactly
> the problems are, and how the suggested solution (e.g., Lamport
> timestamps) solves them.
Sorry for being so unspecific here. I was thinking about a setup where
each server (or small group of servers) has its own database, with all
databases being synchronized. Clients could (potentially) talk to a
different server on each request. These are just some wild ideas so
far, nothing too serious ;)
> Until we iron out those details, I don't think the server-timestamps
> should be any more complex than a simple timestamp.
Agreed.
-- Stefan
Other related posts:
