canmove, Confirmed users
640
edits
User Services/Meta: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (Rnewman moved page User:Rnewman/ServiceDescription to User Services/Meta) |
No edit summary |
||
| Line 3: | Line 3: | ||
Given that Firefox Account is a multi-service account system, and the set of services will grow and change over time, we need a small service to manage the set of service descriptors and allow clients to make and describe their choices. | Given that Firefox Account is a multi-service account system, and the set of services will grow and change over time, we need a small service to manage the set of service descriptors and allow clients to make and describe their choices. | ||
This is one of two privileged services — privileged meaning "directly known to the | That service is the meta service. | ||
This is one of two privileged services — privileged meaning "directly known to the client" — the other being device management itself (which will likely be simply a role of the account system). | |||
The locators for the account server and the meta server are the two pieces of base configuration required to connect to an existing Account/Sync constellation. | |||
== Outline == | == Outline == | ||
The service | The meta service is a standalone service with the same availability and durability requirements as the account service. It exposes a simple API for managing three domain entities: | ||
* Device descriptions. | * Device descriptions. | ||
| Line 19: | Line 23: | ||
* Which services are in use by which connected devices. | * Which services are in use by which connected devices. | ||
Note that this service is 'not' responsible for storing service-specific data: no last-sync timestamps, no preferences for days of history, etc. The general rule of thumb is that if it changes infrequently and is useful for selecting an endpoint it lives here; if it describes the operation of a particular service it lives near that service. | Note that this service is 'not' responsible for storing service-specific data: no last-sync timestamps, no preferences for days of history, etc. The general rule of thumb is that if it changes infrequently and is useful for selecting an endpoint it lives here; if it describes the operation of a particular service it lives near that service; and if it's intimately linked to the lifecycle of sessions, then it lives in the device manager. | ||
This data is used to select, present, and sometimes seamlessly transition between services. | This data is used to select, present, and sometimes seamlessly transition between services. | ||
A service descriptor is the third piece of information needed to set up Sync (or other identity-attached services). Clients can ship with descriptors, or be provided with them by provisioning or from the web (e.g., as with the social providers). Via interaction with the meta server, service descriptors are shared between clients. | |||
== Flow == | == Flow == | ||
[Auth with FxA] => ( | [Auth with FxA] => (client IDs) | ||
[Query SD server] => (services and elections) | [Query SD server] => (services and elections) | ||
[Decide on service and user elections] | [Decide on service and user elections] | ||
| Line 61: | Line 67: | ||
Typically this will be a trivial decision: there will be one or two services, one or two protocols, and a limited feature set. Beyond that most services are likely to be disjoint sets, so I'm not concerned about intractible set cover problems and awkward heuristics. | Typically this will be a trivial decision: there will be one or two services, one or two protocols, and a limited feature set. Beyond that most services are likely to be disjoint sets, so I'm not concerned about intractible set cover problems and awkward heuristics. | ||
== Election == | |||
Note that a compromised meta server could amend any client's elections, causing other clients (or the client itself!) to upload data in a way that would surprise the user. | |||
As such, clients should confirm suggestions with the user prior to acting. | |||
== Protocol transition == | == Protocol transition == | ||
| Line 109: | Line 121: | ||
Note also that this assumes that each device can elect its own datatypes — that is, each can sync a different set of data to a different service. Different user experiences can be layered on this; each device knows the other devices' elections, and can mirror them accordingly. | Note also that this assumes that each device can elect its own datatypes — that is, each can sync a different set of data to a different service. Different user experiences can be layered on this; each device knows the other devices' elections, and can mirror them accordingly. | ||
== Protocol description == | |||
TBD | |||