Services/AppsInTheCloud

From MozillaWiki
< Services
Revision as of 01:20, 16 February 2012 by Mconnor (talk | contribs) (Created page with "= Supporting Apps in Services = The Services team exists to build and support products/services for Mozilla. As part of the consumer launch for Apps, we need to deliver server-...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Supporting Apps in Services

The Services team exists to build and support products/services for Mozilla. As part of the consumer launch for Apps, we need to deliver server-side support for storing/sharing some key data for use by Apps clients (web and native). To deliver on this, we need to identify requirements, and options to fulfil those requirements. This is an attempt to define and document those requirements.

Data Types and Use Cases

Application Receipts

Description

  • Receipts are used to allow users to use purchased apps.
  • Provided at purchase time, required at install (and launch?) for apps
  • Generally additive only, minimal (any?) modifications, no deletes
    • Deletes may be supported in a full-on user account deletion.
  • Must be recoverable in all situations, even after a password reset.

Dataloss implications

  • It is possible to recover/recreate receipts from the market itself, but is likely to be difficult and/or incomplete if a user uses multiple app stores.
  • Users will be unable to install purchased apps on additional devices.
  • Rich clients could be written to restore data to the server, if no data is present, as there will likely be a local cache.

Downtime implications

  • Users will be unable to purchase/obtain new applications
  • Users will be unable to install new apps on additional devices


Device States

Description

  • Device-specific, locally-stored data with server mirroring.
  • Covers install state, enabled state, and any other relevant metadata
  • May be written to from other clients (web, native) to allow remote installs
  • Must be readable from all clients (web, native)
  • Can be recreated by the client if needed

Dataloss implications

  • As long as the device still has the data, it can re-create remote state easily.
  • If server data and device are both gone, the user will need to re-select from list of purchased apps (Application Receipts)

Downtime implications

  • Remote installs/changes will not happen
  • Some dashboard features may be inoperable (if there's a "see what's installed where" feature)


Potential Solutions

Option A

Option B

Option C