48
edits
(→Sub-product ideas: Rename to 'Projects' and update from latest roadmap discussions) |
(→Roadmap brainstorm (subject to change): Move out current/planned work to projects section, leave only "Ideas for Architecture Improvements" section) |
||
Line 147: | Line 147: | ||
* 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. | ||
edits