Confirmed users
483
edits
Firefox OS Data Sync: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (→File sharing) |
No edit summary |
||
| Line 52: | Line 52: | ||
* https://github.com/mozilla-services/kinto | * https://github.com/mozilla-services/kinto | ||
=== Client === | === Client === | ||
Along with the Firefox Cloud server, we will be providing a reference implementation of a Firefox Cloud client. At a high level, this client will need to address at least the following: | |||
* Consume the Firefox Cloud server exposed HTTP API for storing and fetching data from the cloud. | |||
* Conflict resolution. | |||
* Authentication management. | |||
* Encryption and decryption of data. | |||
We would also like it to fulfill the following requirements: | |||
* '''Offline first.''' | * '''Offline first.''' | ||
Ideally we should have a solution where consumers can store the data locally first and then specify that the data needs to be synchronized with a given remote endpoint. The app developer shouldn't need to know the underlying details of the sync protocol, and so instead of using the HTTP API exposed by the Firefox Cloud server, we should provide them with an abstraction to request this synchronization in the form of a JS library. | |||
* '''Avoid enforcing another client storage solution.''' | * '''Avoid enforcing another client storage solution.''' | ||
We already have enough storage APIs in the client side at least on Firefox OS to add another one. We don't think it is a good idea to force developers to use another API for remote data synchronization. Instead, we would prefer a solution that allows developers to keep using the API of their current data source (let's say IndexedDB) for adding, editing and removing records and performing searches. While we can provide an easier abstraction of the current APIs (IndexedDB is known for being a powerful but complicated API), we should still allow developers to keep accessing and using them. | |||
* '''Avoid data duplication.''' | * '''Avoid data duplication.''' | ||
One of the issues that we currently have with DataStore is that we potentially create several copies of the same data across Firefox OS. Ideally, we should not require to do the same with the solution that we choose for the client side of this system. So we should either have a solution that allow us to keep using the same data sources that we use currently but somehow adding the sync capabilities to it or a way to migrate the existing data to a new data source with already sync enabled capabilities. We will certainly need to add meta information along with the existing data that we have in our apps, but this data should have an unique source. | |||
* '''It should be cross browser.''' | * '''It should be cross browser.''' | ||
Whichever solution we find for this, it should work in all browsers. If we end up creating a JS library, we need to be sure that it works (or will work, thinking about [http://caniuse.com/#search=indexeddb IndexedDB support]) in all the major browsers. We believe that we can avoid adding a new web API for this, but in case that we finally need to do it, it would be great if we could standardize it and avoid repeating the DataStore fiasco. | |||
==== Javascript library ==== | |||
===== API ===== | |||
== Current status == | == Current status == | ||
=== Service === | |||
=== Client === | |||