Spec could be more clear about named-client/provider binding. Would "namespace" help?

[toddbaert]

Named client / provider mapping is a useful and important concept. I also think the spec only does the bare minimum in explaining it. I'd like to propose two things:

• add more non-normative text explaining the goal of the concept
• a potential rename of the "name" parameter to "namespace" (not 100% sure on this one)
  • "name" IMO, implies it's a unique identifier for a client instance
  • "namespace", may better convey that there's a relationship to any entities associated with it; it seems obvious that a client and provider belonging to the same namespace are associated
  • I think just changing this param name would be non breaking in SDK implementations

Particularly interested in your thoughts on the namespace proposal @justinabrahms . I think regardless we can add more non-normative text.

cc @thomaspoignant @kinyoklion @beeme1mr @lukas-reining @benjiro

[justinabrahms]

As long as we change the signature to api.getClient(String namespace), then it seems fine to me?

[toddbaert]

As long as we change the signature to api.getClient(String namespace), then it seems fine to me?

Ya, I think we'd basically do that everywhere: name -> namespace as long as there's a general agreement this is actually an improvement.

[Kavindu-Dodan]

I think scope is also a good candidate. For example, a scoped client or a scoped provider where scope is a string . But I am also fine with namespace

[kinyoklion]

I agree that something other than name is good. I do have a bit of a concern about namespace/scope, which is when I hear namespace in this context I think of something like namespace:flagKey (routing:useV2).

Probably doesn't matter, as long as the non-normative text is illustrative enough.

[toddbaert]

I agree that something other than name is good. I do have a bit of a concern about namespace/scope, which is when I hear namespace in this context I think of something like namespace:flagKey (routing:useV2).

hmm, I agree.

[toddbaert]

Closing this for now. This seems to be well-enough understood.