Personal tools

Services/Sync/Features/Addon Sync

From MozillaWiki

< Services | Sync(Difference between revisions)
Jump to: navigation, search
m (add specs)
(documenting possible record choices)
Line 20: Line 20:
 
|Feature overview=Add-ons are synchronized between sync clients.
 
|Feature overview=Add-ons are synchronized between sync clients.
 
|Feature users and use cases=User installs an add-on on one browser. When a sync occurs, the add-on is automagically installed on other sync clients.
 
|Feature users and use cases=User installs an add-on on one browser. When a sync occurs, the add-on is automagically installed on other sync clients.
|Feature functional spec=Add-ons are only synchronized between similar client types (e.g. desktop and mobile). In other words, the add-on set for desktop clients is independent of of that of mobile. The reason for this is add-on compatibility. At the time this was written, most add-ons did not function properly on desktop.
+
|Feature functional spec=Let's assume the following feature set:
 +
 
 +
* Add-ons are only synchronized between clients of the same application ID (e.g. Firefox desktop, mobile, or Thunderbird). The reason is compatibility. Most add-ons simply don't work across multiple application types.
 +
* Given the above, we still need to support syncing add-ons installed on multiple application types.
 +
 
 +
This leads to some interesting choices with regards to the add-on data record. We have the following approaches for record modeling:
 +
 
 +
# Per add-on records
 +
# Per { add-on, application type } pair
 +
# Per client records
 +
 
 +
Per per add-on records would likely resemble the following:
 +
 
 +
ADDON_GUID = {
 +
  clients: {
 +
    A: {
 +
      install_state: "INSTALLED",
 +
      enabled: true,
 +
      type: "desktop",
 +
    },
 +
    B: {
 +
      install_state: "UNINSTALLED",
 +
      type: "mobile"
 +
    }
 +
  }
 +
}
 +
 
 +
For per add-on/application type, we would have:
 +
 
 +
ADDON_GUID-DESKTOP = {
 +
  addons: {
 +
    A: {
 +
      install_state: "INSTALLED",
 +
      enabled: true
 +
    },
 +
    B: {
 +
      install_state: "UNINSTALLED",
 +
      type: "mobile"
 +
    }
 +
  },
 +
  other_prefs: undefined
 +
}
 +
 
 +
And for per-client records, we would have:
 +
 
 +
  CLIENT_ID = {
 +
    app_type: "desktop",
 +
    addons: {
 +
      ADDON1: {
 +
        install_state: "installed",
 +
        enabled: true,
 +
      },
 +
      ADDON2: {
 +
        install_state: "uninstalled",
 +
      },
 +
      ADDON3: {
 +
        install_state: "installed",
 +
        enabled: false
 +
      }
 +
    },
 +
    other_prefs: undefined
 +
  }
 
}}
 
}}
 
{{FeatureInfo
 
{{FeatureInfo

Revision as of 11:28, 11 August 2011

Please use "Edit with form" above to edit this page.

Status

Addon Sync
Stage Definition
Status In progress
Release target TBD
Health OK
Status note `

Team

Product manager Unknown
Directly Responsible Individual Unknown
Lead engineer Gregory Szorc
Security lead Unknown
Privacy lead `
Localization lead Unknown
Accessibility lead `
QA lead Unknown
UX lead Unknown
Product marketing lead Unknown
Operations lead `
Additional members Unknown

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Add-ons are synchronized between sync clients.

2. Users & use cases

User installs an add-on on one browser. When a sync occurs, the add-on is automagically installed on other sync clients.

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

Let's assume the following feature set:

  • Add-ons are only synchronized between clients of the same application ID (e.g. Firefox desktop, mobile, or Thunderbird). The reason is compatibility. Most add-ons simply don't work across multiple application types.
  • Given the above, we still need to support syncing add-ons installed on multiple application types.

This leads to some interesting choices with regards to the add-on data record. We have the following approaches for record modeling:

  1. Per add-on records
  2. Per { add-on, application type } pair
  3. Per client records

Per per add-on records would likely resemble the following:

ADDON_GUID = {
  clients: {
    A: {
      install_state: "INSTALLED",
      enabled: true,
      type: "desktop",
    },
    B: {
      install_state: "UNINSTALLED",
      type: "mobile"
    }
  }
}

For per add-on/application type, we would have:

ADDON_GUID-DESKTOP = {
  addons: {
    A: {
     install_state: "INSTALLED",
     enabled: true
    },
    B: {
      install_state: "UNINSTALLED",
      type: "mobile"
    }
  },
  other_prefs: undefined
}

And for per-client records, we would have:

 CLIENT_ID = {
   app_type: "desktop",
   addons: {
     ADDON1: {
       install_state: "installed",
       enabled: true,
     },
     ADDON2: {
       install_state: "uninstalled",
     },
     ADDON3: {
       install_state: "installed",
       enabled: false
     }
   },
   other_prefs: undefined
 }

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`


Feature details

Priority `
Rank 999
Theme / Goal `
Roadmap `
Secondary roadmap `
Feature list Services
Project `
Engineering team Sync

Team status notes

  status notes
Products ` `
Engineering ` `
Security ` `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `