Services/Sync/Features/Addon Sync

From MozillaWiki
< Services‎ | Sync
Revision as of 19:54, 24 August 2011 by Jarguello (talk | contribs)
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Addon Sync
Stage Definition
Status In progress
Release target TBD
Health Blocked
Status note Product Management needs to flesh out the feature page so that development can be unblocked.

{{#set:Feature name=Addon Sync

|Feature stage=Definition |Feature status=In progress |Feature version=TBD |Feature health=Blocked |Feature status note=Product Management needs to flesh out the feature page so that development can be unblocked. }}

Team

Product manager Jennifer Arguello
Directly Responsible Individual Jennifer Arguello
Lead engineer Gregory Szorc
Security lead Yvan Boily
Privacy lead `
Localization lead Axel Hecht
Accessibility lead `
QA lead Tracy Walker
UX lead Alex Faaborg
Product marketing lead Jaclyn Fu
Operations lead `
Additional members Ibai Garcia (SUMO)

{{#set:Feature product manager=Jennifer Arguello

|Feature feature manager=Jennifer Arguello |Feature lead engineer=Gregory Szorc |Feature security lead=Yvan Boily |Feature privacy lead=` |Feature localization lead=Axel Hecht |Feature accessibility lead=` |Feature qa lead=Tracy Walker |Feature ux lead=Alex Faaborg |Feature product marketing lead=Jaclyn Fu |Feature operations lead=` |Feature additional members=Ibai Garcia (SUMO) }}

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 P2
Rank 999
Theme / Goal Experience
Roadmap Sync
Secondary roadmap `
Feature list Services
Project `
Engineering team Sync

{{#set:Feature priority=P2

|Feature rank=999 |Feature theme=Experience |Feature roadmap=Sync |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=342830"