On Jul 24, 2013, at 10:34 AM, Richard Newman <[email protected]> wrote:
> 2. Device management. Storage requires a fairly strong model of which devices > are connected to the account, when they were last active, what data they've > seen, what capabilities they have, and perhaps other things. Some of this > might be storable in storage itself, but not all -- for example, when a token > is invalidated or a device is removed from a device management UI, this list > needs to be updated. (And a device management UI of course requires such a > list to exist outside of storage, because you might not be using our storage!) > > Some of this begins to morph into service discovery and management -- to have > a list of connected devices, with subsets 'active' for different services. > (Maybe I don't want my reading list active on my work computer.) > > https://bugzilla.mozilla.org/show_bug.cgi?id=821532 covers some of these. > We've anticipated some of this in the auth/key server, but haven't worked through the details. We track currently "active" devices with a long lived session token that the client uses to authenticate itself with auth/key server (e.g., refreshing the signature on the clients public key, which is required to generate assertions for authenticated to the storage server). Having a valid active session token means you're "attached". Changing or reseting your password invalidates all active, valid session tokens. There are lots of details to work out here, but I think this is a good start. > 3. Service discovery and management. This is pretty wooly, but you can > imagine the user scenarios -- when I set up a new machine with just my > username and password, it needs to get my Sync account definition, my Dropbox > credentials for backup, my Pocket account name, etc. > We anticipate the auth/key server will help with this. > (Even if we don't sync third-party-service credentials, we need a service > identifier so the user can log in.) > > * Version negotiation. We need versioning at the protocol level, at the > storage level, and at the data model level. Sync has the first two, but lacks > the third, and it has no concept of negotiation at all -- because negotiation > requires external device management. (Sync stores its client descriptors > inside the system itself!) > What does storage level versioning mean? > I assert that we need data model version negotiation. Experience has shown > that we do not fix or extend our data model for fear of a flag day and > partitioning of devices, and that has two negative effects: firstly, that we > can't later fix bugs we don't know about now; secondly, that we *must* fix > issues we do know about *before* ship, because we can't fix them later. > Neither is good for the schedule. > > See https://bugzilla.mozilla.org/show_bug.cgi?id=825731 for a little sketch > of this. The algorithm for negotiation is fairly obvious, but this needs to > have some integration with the data model. Here's Chromium's take on it: http://www.chromium.org/developers/design-documents/sync/sync-data-best-practices Which probably requires field level encryption to work well. Dropbox File API doesn't work so well with that either, since it's more natural to write/read whole records. New Datastore API would be more friendly to per-field encryption. Warner and I worked though the "no data model versions" option, but it got put on the back burner. What you suggest in the bug is reasonable. -chris
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
