Confirmed users
176
edits
Apps/Sync/Spec2: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Created page with "This document serves as an ''entirely speculative'' revision to the Apps/Sync/Spec specification, with an attempt to make it a bit cleaner and more general. == Expectations ...") |
No edit summary |
||
| Line 14: | Line 14: | ||
For "known" datatypes the sync server ensures the integrity of data, according to the most up-to-date notion of correctness for the data type. As such the sync server must be updated frequently, but clients will be protected from some other rogue clients. ('''Note:''' not sure if this is a practical expectation?) | For "known" datatypes the sync server ensures the integrity of data, according to the most up-to-date notion of correctness for the data type. As such the sync server must be updated frequently, but clients will be protected from some other rogue clients. ('''Note:''' not sure if this is a practical expectation?) | ||
=== Protocol === | |||
We'll go out-of-order time-wise, and forget about authentication for now. | |||
Everything happens at a single URL endpoint, we'll call it /user | |||
Each object looks like this: | |||
{type: "type_name", | |||
id: "unique identifier among objects of this type", | |||
expires: timestamp, | |||
data: {the thing itself} | |||
} | |||
Note the <tt>data</tt> can be any JSONable object, including a string. | |||
The <tt>expires</tt> key is entirely optional, and allows the server to delete the item (if it has not otherwise been updated). | |||
The <tt>id</tt> key must be unique for the type (submitting another key by the same id means that you are overwriting that object). | |||