MozillaWiki

Apps/Sync/Spec: Difference between revisions

Page Discussion

Apps/Sync/Spec (view source)

Revision as of 19:47, 7 March 2012

1,258 bytes added ,  7 March 2012
no edit summary
No edit summary
No edit summary
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This is superseded by the [[Apps/AITC]] spec
== Sync Specification ==
== 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.
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:
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:
Each object must have a <tt>last_modified</tt> key.  The response is only:
Line 120: Line 120:
     {received: timestamp}
     {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"}
     {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 ===
 
The user may delete the data by doing a request to:
 
    POST {collection}?delete
   
    {"reason": "optional text"}
 
This will wipe the data, and further GET calls will then return:
 
    {"collection_deleted": {"reason": "optional text"}}
 
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 ===
== User Interface Concerns ==


While all sync'd applications are in some sense "installed" on all applications, clients (and specifically dashboards) should not treat all applications equivalently.  Applications that were installed from elsewhere should be kept separately from applications installed on the device, unless the user has indicated they specifically want the application on the respective device.
While all sync'd applications are in some sense "installed" on all applications, clients (and specifically dashboards) should not treat all applications equivalently.  Applications that were installed from elsewhere should be kept separately from applications installed on the device, unless the user has indicated they specifically want the application on the respective device.
Line 136: Line 158:
'''NOTE:''' we have to consider what the application picker for Activities looks like too; there is no "dashboard" for Activity picking, so nothing to helpfully distinguish between local and remote apps, or handle app ordering.
'''NOTE:''' we have to consider what the application picker for Activities looks like too; there is no "dashboard" for Activity picking, so nothing to helpfully distinguish between local and remote apps, or handle app ordering.


=== Implementation Notes ===
== Implementation Notes ==


The server implementation is hosted at https://github.com/mozilla/appsync
The server implementation is hosted at https://github.com/mozilla/appsync
Ianb
Confirmed users
176

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/362146...405098"