Apps/Sync/Spec: Difference between revisions

← Older edit

Apps/Sync/Spec (view source)

Revision as of 19:47, 7 March 2012

799 bytes added , 7 March 2012

no edit summary

Ianb

Confirmed users

176

edits

@@ Line 1: / Line 1: @@
+This is superseded by the [[Apps/AITC]] spec
 == Sync Specification ==
@@ Line 107: / Line 109: @@
 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: {...}, ...}
+     [{update1}, {update2}, ...]
 Each object must have a <tt>last_modified</tt> key.  The response is only:
@@ Line 120: / Line 120: @@
      {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''' We need to stick with server timestamps ''always''
 === Deleting the data ===
@@ Line 139: / Line 143: @@
 The client should see this and ask the user if they want to delete the local data.  If the client then does a POST to upload its own data, this erases the deleted state on the collection.
+'''NOTE:''' the data should include a <tt>client_id</tt> in addition to a reason, but we have not indicated what client_id is yet (that is a future feature for sync).
+'''NOTE:''' there's an consistency error that can occur if client A deletes the collection, client B recreates the collection, and client C comes back and doesn't realize that its sense of the last time the syncing was GET/POSTed is based on a collection that essentially doesn't exist anymore.  A way to get around that would be to give the collection a UUID that gets reset when the collection is deleted.  Then the client would see that stuff had changed and would sync everything.
 == User Interface Concerns ==