> 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)
Another option here is auth changeover (the Sync clients have pluggable auth); that's more of a server cost than a client cost. I want to call out that there are some implementation decisions here that concern product owners -- e.g., if we have to have two accounts in Android Settings to make this work. I think Deb is off asking those questions, but we can't rush forward until we get some clarity there. > Thoughts? This looks good to me. I want to take this opportunity to expand the scope of this discussion a little to encompass more milestones. There's an obvious tension between an urge to ship FxA and "fixed Sync" soon -- get *anything* out there, almost regardless of quality -- and the need to build a product that meets our engineering and product needs, both now and going forward: getting a solid product in the market so we can attack the roadmap. I suspect that it's impossible to do both things in one vehicle. There's been some talk over the past few months about using Sync 1.1 plus FxA to achieve some of this. I support doing so, if we can do the following: * Build and deliver device management and service discovery/negotiation, such that we can have one auth flag day, and have the next transition -- to better storage/client/etc -- be managed by our service discovery/capability stuff. We'll need this anyway, and this is point 5 in the last email. * From an engineering/product perspective, we must explicitly regard the Sync 1.1 code as a dead-end (a hacky stopgap), just as it is right now, and don't waste time fixing and extending it beyond life-support. This has the two large caveats: that we absolutely need product buy-in for both stages, and that Mark and Ryan are on board. But there's a real risk that if we don't draw that line, that we'll end up bleeding out fixing a swarm of bugs and never reach our goal. * Relatedly, we should keep a careful eye on the MVP definitions for each branch: the stopgap isn't blind to being viable. We would need to carefully consider whether something like recoverability is a requirement in the short term, for example. During our transition conversation we talked about shipping the new, running in parallel with the old, and then eventually disabling the old. Three solutions, are A (1.1) B (FA on 1.1) C (FA on new storage). 1. Build B 2. Build device management 3. Decide whether we should ship B or wait for C (assume we decide to ship) 4. Ship B (supporting transition from A to B) 5. Build C 6. Disable A and ship C (with automatic transition from B to C) 7. Eventually, disable B, with forced transition from B to C. So there's a forced flag day at step 6 for everyone who hasn't already upgraded, and a decommissioning event at 7. We can do a more gradual conversion of users (opt in) from 4-6 to reduce the impact of the mandatory flag day. In short: get FxA to market, and buy enough time to properly address product and engineering needs. Thoughts? -R _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
