Confirmed users
1,225
edits
Firefox OS Data Sync: Difference between revisions
→2.6
(→2.6) |
|||
| (8 intermediate revisions by 3 users not shown) | |||
| Line 71: | Line 71: | ||
Everything that fits on an indexedDB like database. Including in-app specific settings or things like SMS, call history, alarms, etc. | Everything that fits on an indexedDB like database. Including in-app specific settings or things like SMS, call history, alarms, etc. | ||
== | == Projects == | ||
The Firefox OS Data Sync team will be working on several projects during 2016. | |||
See [https://wiki.mozilla.org/Firefox_OS_Cloud_Roadmap Firefox OS Cloud Roadmap] for an extensive list of product ideas. | |||
=== | === Firefox Sync === | ||
We have implemented import-only bookmarks and history synchronization | |||
for the Smart TV in FxOS 2.5. We will be enabling FxSync on master for phone foxfooders soon. | |||
The next logical step is to finish the work that we started with Firefox Sync | |||
in a way that Firefox OS can catch up with other Firefox Sync clients (Desktop, | |||
Android and iOS). So we need to work on exporting data from the collections that | |||
we already have implemented (bookmarks and history) and work on importing/exporting | |||
from the collections that it still doesn't have (passwords, add-ons, tabs, | |||
preferences, forms, clients). Some of these may not make sense on Firefox OS though. | |||
=== | Also for bookmarks, we still need to define and implement an UI to display the | ||
synchronized bookmarks on the phone. | |||
Finally, we need to allow the creation of new Sync users from Firefox OS. This | |||
involves generating the 'crypto/keys' object containing a new bulk key bundle, | |||
encrypt it with 'kB' on the client and uploading it to the server. | |||
* Stage 1 (completed): Read-only history and bookmarks sync on the Smart TV. | |||
* Stage 2 (completed): Read-only history sync on the phone. | |||
* Stage 3 (to be discussed, [https://groups.google.com/forum/#!topic/mozilla.dev.fxos.sync/DnL1WQ5L24I see ML]): Read-write history sync and passwords sync on the phone. | |||
* Stage 4 (to be discussed, [https://groups.google.com/forum/#!topic/mozilla.dev.fxos.sync/DnL1WQ5L24I see ML]): Sync the [https://docs.services.mozilla.com/sync/objectformats.html rest of the collections] as and when the phone starts supporting these features. | |||
See also https://wiki.mozilla.org/Firefox_OS/Syncto. | |||
=== Media Files Sync === | |||
Planned for 2016. FxOS already allows users to store and view media files using storage that is connected to the device (for instance, an SD-card). Mounting remote cloud storage space (for instance the user's Dropbox or ownCloud account) as a (cached) virtual storage device makes it possible to browse the files on there 'as if' they were on a local storage device. | |||
=== Contacts Sync === | |||
See [https://groups.google.com/forum/#!topic/mozilla.dev.fxos.sync/ctlFp_2_nlA this mailing list thread] for work going on during 2015-Q4. During 2016, we would like to improve the existing sync (currently more a one-shot import) with Gmail and Outlook contacts, and expand it to allow sync with any CardDAV server. | |||
=== Backup / Restore === | |||
Planned for 2016. It should be possible to take snapshots of the entire data state of a Firefox OS device, and later restore that snapshot onto the same or a new device. During Mozlando we will discuss whether this can be a pure peer-to-peer architecture (e.g. using RTCPeerConnection), or whether it will be necessary to store these snapshots on a server where the user has storage space. See https://wiki.mozilla.org/Firefox_OS_Cloud_Backup_Restore for an extensive list of product requirements. | |||
=== Data Sync for the Web === | |||
Apart from launching specific sync features on upcoming Firefox OS versions, we will aim to discuss, build, and standardize the general architecture of data sync technologies that are currently missing on the web platform, but are needed to make data sync on the (mobile) web as easy to use as the data sync features of proprietary single-vendor platforms. | |||
= The solution(s) = | = The solution(s) = | ||
| Line 136: | Line 165: | ||
* CardDav for Contacts. One of the most wanted features (269 votes so far). Check [https://bugzilla.mozilla.org/show_bug.cgi?id=859306 bug 859306]. | * CardDav for Contacts. One of the most wanted features (269 votes so far). Check [https://bugzilla.mozilla.org/show_bug.cgi?id=859306 bug 859306]. | ||
= Ideas for Architecture Improvements = | |||
== SyncEngine shared library == | |||
Right now, the sync engine lives only inside the Sync app that we added for synchronizing bookmarks and history. This works fine as long as the data source to be synchronized is accessible outside of the owner app (via DataStore for example). But it makes it impossible to synchronize an app's data that is not exposed outside of the owner app. Also, having the Sync app managing the synchronization of any kind of data doesn't really scale very well and causes potentially unnecessary data duplication. It makes more sense that each app handles the synchronization of its own data. So in order to allow the addition of new collections (not only existing Firefox Sync collections, but also any other type of collection like contacts, call log or settings data) from any application we need to package the logic of the sync engine in the form of a shared library that can be used by any Gaia application. | Right now, the sync engine lives only inside the Sync app that we added for synchronizing bookmarks and history. This works fine as long as the data source to be synchronized is accessible outside of the owner app (via DataStore for example). But it makes it impossible to synchronize an app's data that is not exposed outside of the owner app. Also, having the Sync app managing the synchronization of any kind of data doesn't really scale very well and causes potentially unnecessary data duplication. It makes more sense that each app handles the synchronization of its own data. So in order to allow the addition of new collections (not only existing Firefox Sync collections, but also any other type of collection like contacts, call log or settings data) from any application we need to package the logic of the sync engine in the form of a shared library that can be used by any Gaia application. | ||
== Sync collection extension mechanism == | |||
Apart from creating this shared library to ease the synchronization process from other apps, we also want to create a way for apps to register themselves in the Firefox Sync machinery. This is, to be able to add their collections to be listed within the Settings UI and to register themselves to be waken up periodically by the sync scheduler that lives in the System app. | Apart from creating this shared library to ease the synchronization process from other apps, we also want to create a way for apps to register themselves in the Firefox Sync machinery. This is, to be able to add their collections to be listed within the Settings UI and to register themselves to be waken up periodically by the sync scheduler that lives in the System app. | ||
== Push notifications in Kinto == | |||
Because we want to avoid unnecessary battery and network consumption by polling constantly from the device but we still want the data to be synchronized as soon as possible, we want to add push notifications to Kinto. This way, when something changes in a remote collection, the server will send every client of this collection a notification about this change so it can update itself accordingly. | Because we want to avoid unnecessary battery and network consumption by polling constantly from the device but we still want the data to be synchronized as soon as possible, we want to add push notifications to Kinto. This way, when something changes in a remote collection, the server will send every client of this collection a notification about this change so it can update itself accordingly. | ||
== Firefox Accounts improvements on Firefox OS == | |||
This is not entirely part of sync, but it is quite related. We are using Firefox Accounts as our identity mechanism. Firefox OS the only platform that still uses BrowserId assertions while other platforms are using the OAuth flow instead. This forces Relying Parties that want to benefit from the SSO system that we have on FxOS to use the non-standard mozId API. It also forces every server side part that we want to create for syncing to support both BrowserId assertions (if we want to sync from FxOS) and OAuth tokens (if we want to sync from Desktop). We aim to move to OAuth as soon as possible. | This is not entirely part of sync, but it is quite related. We are using Firefox Accounts as our identity mechanism. Firefox OS the only platform that still uses BrowserId assertions while other platforms are using the OAuth flow instead. This forces Relying Parties that want to benefit from the SSO system that we have on FxOS to use the non-standard mozId API. It also forces every server side part that we want to create for syncing to support both BrowserId assertions (if we want to sync from FxOS) and OAuth tokens (if we want to sync from Desktop). We aim to move to OAuth as soon as possible. | ||
| Line 180: | Line 194: | ||
== Bugs == | == Bugs == | ||
<bugzilla> | |||
{ | |||
"blocks":"1161657", | |||
"include_fields": "id, summary, component, priority, resolution, assigned_to, depends_on, blocks, whiteboard, cf_blocking_b2g, cf_feature_b2g, target_milestone" | |||
} | |||
</bugzilla> | |||
== Sprints == | == Sprints == | ||
| Line 194: | Line 213: | ||
=== 2.6 === | === 2.6 === | ||
* [[Firefox OS Data Sync/Scrum/fxos2.6-s2|fxos2.6-s2]] | * [[Firefox OS Data Sync/Scrum/fxos2.6-s2|fxos2.6-s2]] | ||
* [[Firefox OS Data Sync/Scrum/fxos2.6-s3|fxos2.6-s3]] | |||
* [[Firefox OS Data Sync/Scrum/fxos2.6-s4|fxos2.6-s4]] | |||
* [[Firefox OS Data Sync/Scrum/fxos2.6-s5|fxos2.6-s5]] | |||
* [[Firefox OS Data Sync/Scrum/fxos2.6-s6|fxos2.6-s6]] | |||
* [[Firefox OS Data Sync/Scrum/fxos2.6-s7|fxos2.6-s7]] | |||
== Stand-up Meetings == | == Stand-up Meetings == | ||