Confirmed users
908
edits
(cleanup / layout improvements) |
|||
| Line 16: | Line 16: | ||
= Questions = | = Questions = | ||
* What is the maximum amount of data that can be stored per user? | * What is the maximum amount of data that can be stored per user? | ||
* Are we storing arbitrary keys or are only well defined keys going to be allowed? No | ** TBC: depends on number of emails and max size for pictures | ||
* Are we storing arbitrary keys or are only well defined keys going to be allowed? | |||
** No | |||
* How often is this data accessed? What is the write pattern? What is the read pattern? (only accessed at registration? not written often?) | * How often is this data accessed? What is the write pattern? What is the read pattern? (only accessed at registration? not written often?) | ||
* How are we handing back the data? | * How are we handing back the data? | ||
* What does the API look like? | * What does the API look like? | ||
* If we launch as an alpha service, how do we handle migration from alpha to beta to release? Not a problem as long as we consult with ops while designing the labs prototype. | * If we launch as an alpha service, how do we handle migration from alpha to beta to release? | ||
** Not a problem as long as we consult with ops while designing the labs prototype. | |||
* Can other services be attached to this DB? Not for now (even though it looks like contacts | * Can other services be attached to this DB? | ||
* What is our timeline? What is the data that we are going to use to decide when this is going to come out of labs and into production? 2012Q1 ;) | ** Not for now (even though it looks like the schema might be similar to contacts) | ||
* What is our timeline? What is the data that we are going to use to decide when this is going to come out of labs and into production? | |||
** 2012Q1 ;) | |||
* What is the data SLA? Where does data need to be backed up? | * What is the data SLA? Where does data need to be backed up? | ||
* What happens when the profile server is down? Does BrowserID sign-in depend on it? You can still login but there's some kind fallback design/graphics for the moocards. | * What happens when the profile server is down? Does BrowserID sign-in depend on it? | ||
* Can we push image resizing / optimizing to the client? | ** You can still login but there's some kind fallback design/graphics for the "moocards". | ||
* Can we push image resizing / optimizing to the client? | |||
** Not all of it (we'll probably be runing optipng/advpng/jpegoptim/pngcrush), but hopefully some of it. | |||
= TODO = | = TODO = | ||
* Look at lloyd's scaling to 1M user wiki page and do something similar (assume everybody is uploading huge pictures we have to resize) | * Look at lloyd's scaling to 1M user wiki page and do something similar (assume everybody is uploading huge pictures we have to resize) | ||
* Talk to security folks, what needs to happen in what order? | * Talk to security folks, what needs to happen in what order? | ||
* Talk to David Ascher and user data group to find out about data collection implications. | * Talk to David Ascher and user data group to find out about data collection implications. | ||
** We need to discuss our plans on dev-identity to sollicit differing opinions | |||
** Write up a document similar to https://da.etherpad.mozilla.org/kpi-backend | |||
* Find out max and average number of emails per user [petef] | |||
* Decide on a maximum image size [skinny] | |||
* Run the moocard idea past skinny [shane] | |||