I need to think more about the tradeoffs of where to put device management. There are compelling reasons for the FA server to manage them. When I think about getting the "last synced" time for each device, it seems more natural for this information to be stored on the storage server. Maybe that just means two API calls to show a list of devices with the times they last synced.
-chris On Aug 11, 2013, at 6:26 PM, Ryan Kelly <[email protected]> wrote: > > Hi All, > > > Here's a quick take on how version-negotiation might look in practice. > I'm deliberately proposing a very blunt and inelegant instrument, in an > attempt to surface what our minimal needs really are. > > Version negotiation is handled at the Firefox Accounts layer, via an API > that lets you list and inspect all the devices attached to the account. > You query the endpoint, and get a set of devices with names and version > strings: > > GET /account/devices > > { > "<device-uuid>": {"name": "Ryan's Laptop", "version", "A.B.X"}, > "<device-uuid>": {"name": "Ryan's Phone", "version", "A.B.Y"}, > } > > Each device is responsible for registering itself when it connects to > the account, and for keeping its details up-to-date. > > We then manage a future protocol or format update as follows: > > 1) We ship FxAccounts + SyncX.Y, without solving all the big thorny > storage problems that we'd really like to solve. > > 2) There's a user-visible flag-day, during which they manually > transfer all their devices over the Firefox Accounts. > > 3) Sometime later we ship FxAccounts + TreeSync, and there is > much rejoicing. > > 4) TreeSync enabled devices check their peers through the device > management api, and delay upgrading to TreeSync until they are > all at some minimal version that's capable of supporting it. > > 5) The user eventually upgrades all their devices, and their data > is transparently migrated into TreeSync without another flag-day. > > 6) Many years from now, we can finally turn off the original storage > servers. > > It's a blunt instrument, but ISTM that this would work OK. > > What I like about putting this in the Firefox Accounts layer, is that it > doesn't block on any other decisions. We could ship this layer on top > of Sync1.1, or Sync2.0, or CouchDB, or whatever happens to be ready at > the time, and we'd have a way to dig ourselves out of whatever mess > we've made (if any!) > > Thoughts? > > More generally: if this really is the only other > absolutely-must-have-before-flag-day feature, then let's get it nailed > down ASAP. > > > Cheers, > > Ryan > _______________________________________________ > 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
