WebExtensions/chrome.storage.sync: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 15: Line 15:
* Is people running their own storage server a priority?
* Is people running their own storage server a priority?
** (andym) no, but it would be nice if they could.
** (andym) no, but it would be nice if they could.
** (tarek) There are 2 paths: 1/ deploy your own service and let it interact with Mozilla to verify FxA tokens. 2/ host everything including your own FxA infra. Michiel has worked on a series of docker images to do 2/
** (tarek) There are 2 paths: 1/ deploy your own service and let it interact with Mozilla to verify FxA tokens. 2/ host everything including your own FxA infra. Michiel has worked on a series of docker images to do 2/ see https://github.com/michielbdejong/fx-self-hosting
* Why Kinto over Sync?  
* Why Kinto over Sync?  
** (tarek) the Kinto server stores the data in postgres RDS instead of Sync's ad-hoc Mysql deployment. RDS comes with data replication, meaning that we have less chances to lose data for users.  
** (tarek) the Kinto server stores the data in postgres RDS instead of Sync's ad-hoc Mysql deployment. RDS comes with data replication, meaning that we have less chances to lose data for users.  

Revision as of 14:02, 7 March 2016

Planning for implementing chrome.storage.sync for WebExtensions.

There are two components to this API: the API in Firefox and the backend storage servers. Prototype is done.

tl;dr an add-on developer can save some data related to the add-on and it is accessible to the same add-on for that user on different profiles and devices. See the Chrome docs for more.

Firefox API

  • this was added in the prototype on github
  • the existing code will need to be ported into mozilla-central and tested properly
  • we will use Firefox Accounts for authentication of the user

Questions

  • Is people running their own storage server a priority?
    • (andym) no, but it would be nice if they could.
    • (tarek) There are 2 paths: 1/ deploy your own service and let it interact with Mozilla to verify FxA tokens. 2/ host everything including your own FxA infra. Michiel has worked on a series of docker images to do 2/ see https://github.com/michielbdejong/fx-self-hosting
  • Why Kinto over Sync?
    • (tarek) the Kinto server stores the data in postgres RDS instead of Sync's ad-hoc Mysql deployment. RDS comes with data replication, meaning that we have less chances to lose data for users.
  • How long do we retain data?
  • Is there a way to clear out data?
    • (tarek) yes, that's a API call away with the proper permissions
  • As a user can I see what data is stored by each add-on?
  • Edge cases
    • What happens when a user isn't logged in?
      • (tarek) we store stuff locally and don't sync them
    • What happens when the client goes offline?
      • (tarek) the client should gracefully wait for the next chance to sync with the server. The Kinto client has built-in offline first features.
    • How does it resolve when there's a conflict?
      • (andym) it doesn't, it just overwrites

Bugs for porting this over can hang off 1220494:

Full Query
ID Priority Status Summary
1311510 P3 NEW chrome.storage.sync: performance test of production stack for chrome.storage.sync

1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%);


Storage servers

...Tarek to fill in.

The bugs for tracking the roll out are:

Timelines

  • Stand up the client code, behind a feature flag, so that users have to flip it on in about:config
  • Stand up the servers.
  • Find some add-ons to be beta-testers.