On Aug 12, 2013, at 4:26 AM, 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,
+1
> 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.
+1
> 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.
+1
> 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!)
+1
> More generally: if this really is the only other
> absolutely-must-have-before-flag-day feature, then let's get it nailed
> down ASAP.
>
> Thoughts?
I'm four on the positive side for an approach like this. The only missing bit
would seem to be the server knowing what "version" of storage you're on. A
connected client can say "oh look, all versions of a users device support
fancy-new storage back end, and I'm back on crufty sync X.Y, let me migrate".
Then other devices come on line and say "oh look! I've got a local crufty
version of data, but the database was updated, let me ditch this old code-path
and re-sync with the new hotness".
Is this the general idea you're thinking about for how we can iterate data
storage in the future? If so, I like it.
lloyd
>
> 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
