MozillaWiki

Services/Sync/Features/Addon Sync

< Services‎ | Sync
Revision as of 23:04, 16 August 2011 by Philikon (talk | contribs)
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 `

{{#set:Feature name=Addon Sync

|Feature stage=Definition |Feature status=In progress |Feature version=TBD |Feature health=OK |Feature 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

{{#set:Feature product manager=Unknown

|Feature feature manager=Unknown |Feature lead engineer=Gregory Szorc |Feature security lead=Unknown |Feature privacy lead=` |Feature localization lead=Unknown |Feature accessibility lead=` |Feature qa lead=Unknown |Feature ux lead=Unknown |Feature product marketing lead=Unknown |Feature operations lead=` |Feature 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

` {{#set:Feature open issues and risks=` |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 dependencies=` |Feature requirements=` |Feature non-goals=` |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:

  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
 }

|Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

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

{{#set:Feature priority=`

|Feature rank=999 |Feature theme=` |Feature roadmap=` |Feature secondary roadmap=` |Feature list=Services |Feature project=` |Feature engineering team=Sync }}

Team status notes

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

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Discussion notes from 2011-08-16:

  • add 'guid' column to 'addon' table in extensions.sqlite
  • add GUID support to AddonsManager (have it automatically generated, 12 chars base64url)
  • findings addons shouldn't count as daily update pings, or if they do, is it a problem?
  • generate one record per app per addon, silently drop records from other apps and unknown addons (unknown to AMO)
  • add option to locally disable enabled state sync (the "web developer case") in about:config
Retrieved from "https://wiki.mozilla.org/index.php?title=Services/Sync/Features/Addon_Sync&oldid=340518"