Mostly just a +1. The plan is concise and incremental. It's exactly what we need. Nice work. I don't see any red flags to add FFOS along the way. We might volunteer as first post sync-1.1 storage backend consumer once that part shakes out after milestone 1. We will try to share the desktop HTML UI, with tweaks. I am still worried about hosting primary UI but if that turns into a problem we can always client package it and stick with HTML so I don't think that decision creates unmanageable risk.
Lets get it done. Andreas Sent from Mobile. On Aug 15, 2013, at 2:03, Lloyd Hilaiel <[email protected]> wrote: > A lot of people have been doing a lot of talking. There is rough consensus > around a short term plan for the client implementation team. I've worked > with nick, chris, mfinkle, rnewman and others to figure all this out (they > did all the work, I just type). Here's an attempt to distill that, blow me > up publicly if I say something you can't live with. > > What's the target? Milestone 1 - Firefox Accounts delegating to existing > Sync 1.1 account > > We are going to take the mocks we have and build a fully functional subset of > MVP. This is going to have the following properties: > > 1. implements UX mocks for Firefox Account setup and management on desktop > and Android (no FirefoxOS for milestone 1) > 2. implements Firefox Account password-based flow against picl-idp.org > described at (need a git revision or other stake in the ground here) > backend comfort by mark mayo ala rfk are pre-requisites to shipping? > 3. invisibly creates a Sync account to do the actual Syncing (so no major > desktop code changes needed) (this might require using a stage Sync server to > avoid captchas) > 4. stores data using the current Sync implementation (does not change the > existing sync codebase) (storage architecture 1.1) > 5. scope work required to avoid future flag days (but implementation not part > of milestone 1) > > Who's doing the work: > > picl-idp: dcoates is the lead, with support from rfk, zaach, and dev/ops to > be determined > Android: Nick Alexander is the lead. > Desktop: Lloyd Hilaiel is the lead in constant contact with Gavin, Dolske, > and ttalbert > Future storage scoping work continues in parallel by: ckarlof working closely > with rnewman & warner > > On android and desktop sides we'll pull in additional help as needed. > > What's next: > > First step is to define the steps to get to milestone one. That happens > below. > > Second step is for Nick Alexander to break this down into granular bugzilla > bugs for implementation on the android side (happening today). > > Third step is for lloyd to map these bugs over to desktop. (happening > tomorrow) > > Fourth step is to knock them down one by one, with code landing in ELM. > > Key Steps: > > 1a. On Desktop implement HTML based authentication - sign up/sign in > 1b. On Android, implement native Account and native UI authentication flow > > 2. On both platforms, use Sync 1.1 user API > (http://docs.services.mozilla.com/reg/apis.html) to create a "derived" Sync > user account with username, password, and encryption keys derived from the > Firefox Account settings. [1] > > 3. On both platforms, use derived Sync account to store data into existing > Sync 1.1 > > Thoughts? > > lloyd > > [1] On Android, this will look weird -- there will be a Firefox Account and a > Sync Account at the same time. This is temporary. If we really care to make > this look slick, we can make the delegated Sync account go away. On Desktop, > there will be the usual evidence of Sync. > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
