Namespace hierarchy assumptions in the context of client generation with useAuth

[MaryGao]

We have similar discussions in this but the hierachy assumptions are still unclear for me when mapping to our new client design. Here are my assumptions and questions.

• Case 1: One auth with root namespace
• Case 2: Different auth in different namespace

Case 1: One auth with root namespace

@service({
  title: "Widget Service",
})
@useAuth(BearerAuth | ApiKeyAuth<ApiKeyLocation.cookie, "session-id">)
namespace Todo {
  @route("/users")
  namespace Users {
    op create(): void;
  }

  @route("/items")
  namespace TodoItems {
    op create(): void;
  }
}

Assumptions:

• The top-level client Todo accepts a parameter for authentication (e.g., BearerAuth or ApiKeyAuth).
• The top-level client contains two sub-clients: Users and TodoItems. Both of them would share the parent authentication.
• For all sub-clients they will inherit all parameters from the top-level client but can't add or override parameters from their parent.
  • their access would be Access.internal which means they can't be initialized separately;
  • their accessorAccess would be Access.public which means they could be got from parent client.

Case 2: Different auth in different namespace

@service({
  title: "Widget Service",
})
@useAuth(BearerAuth | ApiKeyAuth<ApiKeyLocation.cookie, "session-id">)
namespace Todo {
  @useAuth(NoAuth)
  @route("/users")
  namespace Users {
    op create(): void;
  }

  @route("/items")
  namespace TodoItems {
    op create(): void;
  }
}

Assumptions:

• The top-level client Todo accepts a parameter for authentication (e.g., BearerAuth or ApiKeyAuth).
• The top-level client contains two sub-clients: Users and TodoItems. Sub-client Users would override the parent's authentication parameter to align with NoAuth. TodoItems would share the parent authentication.
• For all sub-clients they will inherit all parameters from the top-level client but can't add or override parameters from their parent.
  • their access would be Access.internal which means they can't be initialized separately;
  • their accessorAccess would be Access.public which means they could be got from parent client.

If we trust the assumption that useAuth should not change the hierarchy, we may see the contradictory point in client Users which requires a construtor overriding but is not allowed to override. One way to correct the conflict is to use @clientInitialization.

@@clientInitialization(Users , {access: Access.public, accessorAccess: Access.internal});

I know most of SDK emitters has yet to support different authentication for different clients but considering this would impact the client hierarchy, Could we settle down following questions to reduce future potential breakings?

• With above two cases, is the assumption correct?
• Do we have the same assumption in Azure and unbranded area?
• Do we allow useAuth to change the sub-client's access?
• Can @clientInitialization be used in both Azure and unbranded area?

/cc @joheredi @tadelesh @ArcturusZhang @weidongxu-microsoft

[wanlwanl]

Playground
Since OAS3 emitter doesn't support sub-client, it generate for different paths instead, and each operations inherit/override namespace's auth. e.g. root namespace PetStores auth is overrided by Todo namespace, and operation TodoItems_create inherits Todo namespace's auth. While Users_create operation uses its own auth.
So OAS3 emitter follows the assumption. And due to OAS3 doesn't support subclient, it doens't has access and accessorAccess.