WebExtensions/chrome.storage.sync: Difference between revisions
Jump to navigation
Jump to search
Full Query
Tarek.ziade (talk | contribs) |
Tarek.ziade (talk | contribs) |
||
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/ | |||
* 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 13:42, 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/
- 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
- What happens when a user isn't logged in?
Bugs for porting this over can hang off 1220494:
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.