The Basics
-
Which design guideline is affected?
This is a request to establish guidelines for the use of management APIs within a data plane library.
In Service Bus, there is a management client that uses the ATOM XML standard over HTTP. This is separate from the auto-generated ARM client. The ATOM client is scoped to CRUD operations within a particular namespace, whereas ARM can be used across namespaces. Also, the ATOM client allows authenticating with a connection string whereas ARM does not. During the initial implementation of Track 1, there was an attempt to remove the ATOM client (which was around in Track 0), but this was met with much resistance from the community and it was left in, primarily due to ARM not supporting connection strings. Because of this history, we are planning to go forward with continuing to support the ATOM client in Track 2.
-
Which target languages are affected?
.NET, Java, Python, JS
-
Describe the change:
A new guideline that explains under what scenarios management APIs may be included in a data plane library and what conventions should be followed for said management API.
In particular:
- How do we position the real mngmt plane (arm) and such data-plane based mngmt plane APIs?
- How do we position this new management plance and the data plane?
- What conventions we would use to communicate to developers the difference in the APIs? E.g. namespace, package, type naming.
Reasoning
There will likely be other libraries that will want to have management API included in the data plane. It would be good to establish a guideline for how this should be handled to ensure consistency.
The Basics
Which design guideline is affected?
This is a request to establish guidelines for the use of management APIs within a data plane library.
In Service Bus, there is a management client that uses the ATOM XML standard over HTTP. This is separate from the auto-generated ARM client. The ATOM client is scoped to CRUD operations within a particular namespace, whereas ARM can be used across namespaces. Also, the ATOM client allows authenticating with a connection string whereas ARM does not. During the initial implementation of Track 1, there was an attempt to remove the ATOM client (which was around in Track 0), but this was met with much resistance from the community and it was left in, primarily due to ARM not supporting connection strings. Because of this history, we are planning to go forward with continuing to support the ATOM client in Track 2.
Which target languages are affected?
.NET, Java, Python, JS
Describe the change:
A new guideline that explains under what scenarios management APIs may be included in a data plane library and what conventions should be followed for said management API.
In particular:
Reasoning
There will likely be other libraries that will want to have management API included in the data plane. It would be good to establish a guideline for how this should be handled to ensure consistency.