Apps/Sync/Spec: Difference between revisions

Apps/Sync/Spec (view source)

Revision as of 16:41, 29 November 2011

178 bytes removed , 29 November 2011

→‎Sending new updates

Tarek.ziade

Confirmed users

927

edits

@@ Line 107: / Line 107: @@
 The client should keep track of the last time it sent updates to the server, and send updates when there are newer applications.
-'''NOTE:''' there is a case when an update might be lost because of an update from another device; this would be okay except that the client doesn't know it needs to re-send that update.  How do we confirm that?
 The updates are sent with:
-     POST {collection}?since={timestamp}
+     POST {collection}?lastget={timestamp}
      {origin: {...}, ...}
@@ Line 120: / Line 118: @@
      {received: timestamp}
-<tt>since</tt> should be the time of the last GET (that the client did), and the server checks it against the time of the last POST to the collection.  If a client is issuing a POST but hasn't seen updates from another client, then this will fail like:
+<tt>lastget</tt> should be the time of the last GET (that the client did), and the server checks it against the time of the last POST to the collection.  If a client is issuing a POST but hasn't seen updates from another client, then the client receives a 412 Precondition Failed.
      {status: "failure", reason: "conflict"}
-'''NOTE:''' this is like a precondition (If-Unmodified-Since or If-Match), and there is a response 412 Precondition Failed.  We could use those?  We are using float timestamps instead of HTTP dates; we could use X-If-Unmodified-Since or use ETag.  I don't believe, but am not sure, that we need to understand the timestamps as a newer/older kind of thing.  At least for this case (<tt>last_modified</tt> is different).
+'''NOTE:''' We could use (If-Unmodified-Since or If-Match or ETag) instead of lastget. We are using float timestamps instead of HTTP dates; we could use X-If-Unmodified-Since or use ETag.  I don't believe, but am not sure, that we need to understand the timestamps as a newer/older kind of thing.  At least for this case (<tt>last_modified</tt> is different).
+'''NOTE:''' using <tt>last_modified</tt> on the client makes us vulnerable to time differences between client and server.  We may not really need to use <tt>last_modified</tt> and could just send everything that hasn't been sent, then no local timestamps will be used.
-'''NOTE:''' using <tt>last_modified</tt> on the client makes us vulnerable to time differences between client and server.  We may not really need to use <tt>last_modified</tt> and could just send everything that hasn't been sent, then no local timestamps will be used.
+'''NOTE''' We need to stick with server timestamps ''always''
 === Deleting the data ===