[gpodder-devel] my.gpodder episode sync design problem: "since" values
- From: dovdevel at gmail.com (Dov Feldstern)
- Date: Mon, 4 Jul 2011 00:35:07 +0300
On Sat, Jul 2, 2011 at 14:55, Stefan K?gl <koeglstefan at gmail.com> wrote:
>
> I'm currently thinking about a solution that would include both
> approaches. For each action two timestamps are stored, the current one
> from the client and a server-timestamp that is used for
> synchronization. The server-timestamps could be implemented as Lamport
> timestamps to make it possible (in the future) to distribute
> gpodder.net over multiple servers. Additionally when doing the switch
> from the current system, the server-timestamps could be initialized
> with the current UTC timestamp so that we don't break any clients.
>
> What do you think about this solution?
>
Basically, this sounds good, but I'd like to go into a little more detail:
First of all, I think we should separate between single-server and
multi-server, I think multi-server is significantly more complicated.
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. 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). The "since" values returned by the server will (continue
to?) be server-based timestamps.
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.
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.)
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.
Until we iron out those details, I don't think the server-timestamps
should be any more complex than a simple timestamp.
Dov
Other related posts:
