Cloud Services/FirefoxOS Sync: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 4: Line 4:
== Objective ==
== Objective ==


If we call this sync, everyone will be confused
This is a proposal for a framework on FirefoxOS to support apps that wish to synchronize data with a remote server.  The framework itself would not provide a means of performing sync; it is not a "sync engine".  It would instead permit apps to request to be awakened in the background to sync data periodically.  When conditions were suitable (e.g., wifi were available, system load were low), apps would be awakened in turn and given some time to sync.  An app awakened for background sync should be given some protection by the system, such as a better OOM-kill score, to increase the likelihood that it would complete successfully.


Some things Firefox and Google are both pushing for:
Several proposed standards and work in progress on FirefoxOS would support this system, in particular:


* https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md <== HERE
* [https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md BackgroundSync]
* https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md
* [https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md ServiceWorkers]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1014023 system messages to wake apps on DataStore change]
 
== Examples ==
 
Consider an app
 
One of our first use cases


There are shared and private data types on fxos
There are shared and private data types on fxos
Line 18: Line 25:


both should be able to have a backing store that can sync with the apps on device
both should be able to have a backing store that can sync with the apps on device
== Architecture ==
[[File:Fxos sync v1.png|frameless|left]]


== Use Cases ==
== Use Cases ==

Revision as of 17:24, 22 May 2014

Work In Progress - Nothing Final Here

Objective

This is a proposal for a framework on FirefoxOS to support apps that wish to synchronize data with a remote server. The framework itself would not provide a means of performing sync; it is not a "sync engine". It would instead permit apps to request to be awakened in the background to sync data periodically. When conditions were suitable (e.g., wifi were available, system load were low), apps would be awakened in turn and given some time to sync. An app awakened for background sync should be given some protection by the system, such as a better OOM-kill score, to increase the likelihood that it would complete successfully.

Several proposed standards and work in progress on FirefoxOS would support this system, in particular:

Examples

Consider an app

One of our first use cases

There are shared and private data types on fxos

shared include contacts, calendar, photos

private would be whatever an app might come up with (cupcake recipes, etc.)

both should be able to have a backing store that can sync with the apps on device

Architecture

Fxos sync v1.png

Use Cases

  • install a flickr app, and your photos get uploaded to flickr ("sync")
  • install a Google+ app, and your photos also get uploaded. Do both at once!
  • install Delicious app, sync bookmarks (pending a bookmark DOM API, which we don't have)
  • Facebook keeps its contacts in sync.
  • Fruux backup keeps contacts in sync, EXCEPT Facebook contacts
  • provision identity on fruux using firefox accounts assertion

Features

Scheduling

when resources permit (memory, wifi)

Aware of network cost (e.g., wifi only, nighttime minutes)

provide each app some assurance that it won't get OOM-killed while working

make sure each app is done within 5 minutes or so

feedback on success/failure?

Precedent: alarm API.

  • Doesn't account for cases where you don't want the app to be woken up (e.g., the e-mail app shouldn't check for new messages if the phone's battery is running low).
  • Can't wake up the app when an external event happens (e.g., you're on Wi-Fi). Scheduling becomes interesting, too; 10 apps shouldn't be woken up simultaneously.

UX Challenges

  • how does the user know this is going on in the background?
  • how can the user know about resource usage per app?
  • if i'm on a limited data plan, there should be a way for me to know that there's a crappy app that's hoovering up all my data (existing network stats? per-app data usage?)
  • dovetailing with success/failure feedback - something like android's notifications that "15 photos synced three minutes ago" - toaster pops down and tells you the results. simple, unobtrusive, non-blocking affordances to tell you that things worked.
  • if there's a sync app, where do users find it? (preinstalled, probably) but not a certified app, so it can be updated. it would show up as an update, as play services on android - you can't open that app, but you can update it out-of-cycle
  • would be nice to identify such apps as special in some way - they don't have a launcher, etc. (something in the manifest for this already? "role"?)
  • services app could be bundled with various other apps?

Architecture