I realized that I haven't explicitly articulated this list, and there might be things I'm missing.
Here's my view of the ecosystem in which storage operates. 1. Identity provider, keyserver, et al. I think y'all have a good handle on this. 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. 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. (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!) 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. What am I missing? -R _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
