Apps/Sync/Spec - Revision history

Ianb at 19:47, 7 March 2012

2012-03-07T19:47:12Z

← Older revision		Revision as of 19:47, 7 March 2012
Line 1:		Line 1:
	This is superseded by the [Apps/AITC] spec		This is superseded by the [[Apps/AITC]] spec

	== Sync Specification ==		== Sync Specification ==

Ianb at 19:46, 7 March 2012

2012-03-07T19:46:40Z

← Older revision		Revision as of 19:46, 7 March 2012
Line 1:		Line 1:
			This is superseded by the [Apps/AITC] spec

	== Sync Specification ==		== Sync Specification ==

Ianb: /* Sending new updates */

2011-11-29T19:28:35Z

Sending new updates

← Older revision		Revision as of 19:28, 29 November 2011
Line 112:		Line 112:
	POST {collection}?lastget={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:

Tarek.ziade: /* Sending new updates */

2011-11-29T16:41:03Z

Sending new updates

← Older revision		Revision as of 16:41, 29 November 2011
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.		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: {...}, ...}		{origin: {...}, ...}
Line 120:		Line 118:
	{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:''' ~~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 ===		=== Deleting the data ===

Ianb: /* Sending new updates */

2011-11-03T22:10:07Z

Sending new updates

← Older revision		Revision as of 22:10, 3 November 2011
Line 125:		Line 125:

	'''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:''' 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:''' 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.

	=== Deleting the data ===		=== Deleting the data ===

Ianb: /* Deleting the data */

2011-11-03T18:17:26Z

Deleting the data

← Older revision		Revision as of 18:17, 3 November 2011
Line 141:		Line 141:

	'''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:''' 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 ==

Ianb: /* Deleting the data */

2011-10-31T18:40:56Z

Deleting the data

← Older revision		Revision as of 18:40, 31 October 2011
Line 139:		Line 139:

	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.		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).

	== User Interface Concerns ==		== User Interface Concerns ==

Ianb: /* Sending new updates */

2011-10-31T18:39:29Z

Sending new updates

← Older revision		Revision as of 18:39, 31 October 2011
Line 113:		Line 113:

	POST {collection}?since={timestamp}		POST {collection}?since={timestamp}

	{origin: {...}, ...}		{origin: {...}, ...}

Ianb: /* Deleting the data */

2011-10-31T18:39:08Z

Deleting the data

← Older revision		Revision as of 18:39, 31 October 2011
Line 131:		Line 131:

	POST {collection}?delete		POST {collection}?delete

	{"reason": "optional text"}		{"reason": "optional text"}

Ianb at 18:37, 31 October 2011

2011-10-31T18:37:33Z

← Older revision		Revision as of 18:37, 31 October 2011
Line 126:		Line 126:
	'''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:''' 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).

	=== User Interface Concerns ===		=== 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.

			== 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 150:
	'''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