The service_manager::Identity type is a string triplet consisting of service name, "user ID", and an "instance" qualifier. These three fields each serve a distinct and useful purpose, but the terminology can be confusing.
In particular, there is no actual correlation between "user ID" and anything resembling an actual "user" on the host system. More generally, the field is used to isolate groups of service instances from others, and to allow services in a specific group to automatically have their requests routed by default (and often exclusively) to other services within the same group. As such, the term "partition" more generically encapsulates this function without being so specific as "user".
Furthermore, both the user ID (henceforth "partition") and instance fields are free-form strings, but in practice both require only the capacity for uniqueness. Human readability is an uninteresting constraint, and in practice we tend to use GUID strings for these fields anyway. As such, they can be more efficiently represented as UnguessableToken fields.
Finally, an Identity received from the Service Manager (via either Service::OnStart, or various ServiceManagerListener notifications) is not currently guaranteed to map 1:1 to actual service instances. This is because a service Identity (A,B,C) may be reused if an instance dies and is restarted by the Service Manager, yet there is no guarantee of relative ordering between client-facing events pertaining to the old instance against client-facing events pertaining to the new one. Bug 840127 covers this in more detail. TL;DR: we add one more UnguessableToken to Identity, which is treated strictly as a GUID identifying the specific instance uniquely across all time and space.
The service_manager::Identity type is a string triplet consisting of service name, "user ID", and an "instance" qualifier. These three fields each serve a distinct and useful purpose, but the terminology can be confusing.
In particular, there is no actual correlation between "user ID" and anything resembling an actual "user" on the host system. More generally, the field is used to isolate groups of service instances from others, and to allow services in a specific group to automatically have their requests routed by default (and often exclusively) to other services within the same group. As such, the term "partition" more generically encapsulates this function without being so specific as "user".
Furthermore, both the user ID (henceforth "partition") and instance fields are free-form strings, but in practice both require only the capacity for uniqueness. Human readability is an uninteresting constraint, and in practice we tend to use GUID strings for these fields anyway. As such, they can be more efficiently represented as UnguessableToken fields.
Finally, the Identity values received from the Service Manager (via either Service::OnStart, or various ServiceManagerListener notifications) are not currently guaranteed to map 1:1 to actual service instances. This is because a service Identity (A,B,C) may be reused if an instance dies and is restarted by the Service Manager, yet there is no guarantee of relative ordering between client-facing events pertaining to the old instance and client-facing events pertaining to the new one. Bug 840127 covers this in more detail. TL;DR: we add one more UnguessableToken to Identity, which is treated strictly as a GUID identifying the specific instance uniquely across all time and space.
Moving the discussion here. FWIW the reasons I liked "partition" better than "instance group" are:
a) to me partition carries an implied connotation of serving as a kind of security boundary
b) less typing!
But the rhythm of "instance group" and "instance" is nice too. Eh...
Comment 1 by roc...@chromium.org
, Oct 15