Cloud Services/FirefoxOS Sync
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 general-purpose "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
Periodic sync
1. The App is installed with permission to read/write data type T. It wants to sync the T DataStore with a remote service. So its ServiceWorker sends a requestSync message, specifying the duration of the interval between sync requests.
2. The App also wants to watch T for changes, so its ServiceWorker registers a listener with the DataStore, asking to be notified on any changes. (See one-time sync below.)
3. Some time in the future, the Scheduler perceives that it is time for the App to sync. It enqueues the App for the next available sync opportunity (e.g., when the network is available).
4. When it is a good time to sync, the Scheduler sends a sync message to the App's ServiceWorker. This awakens the worker, but does not display the app. The app can now pull and push. (The app is responsible for the sync logic.)
One-time sync
1. Some other App modifies the data in DataStore T. The App's ServiceWorker receives a change notification (see 2 above).
2. The notification wakes the App up in the background.
3. The ServiceWorker sends a non-repeating, immediate requestSync.
4. The app shuts down.
5. The Scheduler receives the sync request. At the next opportunity, it wakes the App with a sync message, and the App syncs the changed data.
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?