You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Add server-side support for plumbing requested and activated extensions (#333)
# Description
This adds PR adds support for reading requested extensions from a
client, via the `X-A2A-Extensions` header, and plumbing that through the
ServerCallContext.
Here's my rough thinking on the design choices:
1. Requests to activate extensions are specified in a transport-specific
manner. For HTTP, it's using headers. For gRPC, it's using side-channel
metadata (which are also HTTP headers).
2. However, indicating that an extension was requested is a
transport-independent concept. So, it should be passed to the
transport-independent layers of the SDK.
3. We already have a means of extracting relevant information from the
transport layer (and others) and passing down to the independent layers:
the `ServerCallContext`.
4. So, we can put the list of requested extensions here. The transport
layers are responsible for pulling out the list of requested extensions
in whatever transport specific means they are communicated, and passing
these down via the ServerCallContext.
5. Returning the list of extensions that were activated is slightly more
annoying. I didn't want to have to refactor every layer to plumb both
the request-specific response type (such as SendMessageResponse) AND the
list of extensions activated. That's just too intrusive.
6. So, I need some way to communicate the list of activated extension
from the independent layers back "up" to the transport layers via
something other than the return value. I'm not thrilled with the
decision here, but the answer is to use interior mutability: I put a
mutable set in the ServerCallContext, and allow lower levels to modify
it to add the activated extensions.
7. The transport layers then need to read the list of activated
extensions from the ServerCallContext and pass those back in the
response in the transport-defined method.
The result is that we have full stack plumbing of requested and
activated extensions by way of the ServerCallContext.
---------
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: Holt Skinner <[email protected]>
Co-authored-by: Holt Skinner <[email protected]>
0 commit comments