From 79e2723437b2387555afc39e722ac19940ee8441 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marcel=20Wien=C3=B6bst?= Date: Fri, 30 Oct 2026 15:14:22 +0100 Subject: [PATCH 1/2] docs(adr): add draft of code generator for context registry ADR --- ...0006-openapi-generator-context-registry.md | 45 +++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 adr/0006-openapi-generator-context-registry.md diff --git a/adr/0006-openapi-generator-context-registry.md b/adr/0006-openapi-generator-context-registry.md new file mode 100644 index 00000000..526c5bf3 --- /dev/null +++ b/adr/0006-openapi-generator-context-registry.md @@ -0,0 +1,45 @@ +# OpenAPI Generator for Context Registry + +## Status + +Under discussion + +## Context + +The [context registry service](https://github.tools.sap/AI/context-registry) is currently not supported in the Python SDK. The Java and JS SDKs heavily rely on code generation and will generate the new client for context registry from [the spec](https://github.tools.sap/AI/context-registry/tree/main/src/spec). The Python SDK, on the other hand, is currently fully manually written. Code generation has been explored as a future option, see [ADR 0004](https://github.com/SAP/ai-sdk-python/blob/main/adr/0004-openapi-generators.md) and [this PoC](https://github.com/SAP/ai-sdk-python/pull/99) introducing the OpenAPI generator including a working client for the context registry service. This ADR decides how the context registry client will be added to the Python SDK: with code generation or as a manually written client. + +## Decision + +TBD + +## Consequences + +TBD + +## Appendix + +### Option A (Handwritten Client) + +Pros: + +- Fully aligned with the current general approach and coding style in the SDK +- For the context registry spec on its own, adding the client manually would be faster than first introducing a code generator + +Cons: + +- Higher maintenance effort +- More difficult to keep up-to-date with spec changes (no automation) + +### Option B (Generated Client) + +Pros: + +- Lower maintenance effort, in particular if code generation is used for multiple services (not only context registry) +- Easy to regenerate client code in case of spec changes +- Consistent with the approach in the Java and JS SDK + +Cons: + +- Need to maintain code generator including customizations (however, Java and JS SDKs report this cost being lower than keeping the clients up-to-date manually) +- Initially adding the generator takes time and effort +- The generated client will stylistically not be fully consistent with the manually written clients in the SDK (for example with regard to how the `ai_resource_group` header is handled) From eeb22e8989a5059fa3e049c5b2585a4d39be89b1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marcel=20Wien=C3=B6bst?= Date: Fri, 30 Oct 2026 15:18:42 +0100 Subject: [PATCH 2/2] small fix --- adr/0006-openapi-generator-context-registry.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/0006-openapi-generator-context-registry.md b/adr/0006-openapi-generator-context-registry.md index 526c5bf3..7f2c1798 100644 --- a/adr/0006-openapi-generator-context-registry.md +++ b/adr/0006-openapi-generator-context-registry.md @@ -18,7 +18,7 @@ TBD ## Appendix -### Option A (Handwritten Client) +### Option A (Manually-written Client) Pros: