: Etherpad users! We are developing an extension that will allow you to create pages from etherpads quickly and easily. Please visit our sandbox and help us test it.

Difference between revisions of "Services/Sync/Features/Addon Sync"

From MozillaWiki
< Services‎ | Sync
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 ` `