Client transports: make #protocolVersions() configurable#669
Conversation
86ae5fe to
1042cb9
Compare
Signed-off-by: Daniel Garnier-Moiroux <[email protected]>
2554994 to
c293f09
Compare
tzolov
left a comment
There was a problem hiding this comment.
Nice job @Kehrlann . I like the test utils.
Left a comment about the name of the "working" protocolVersion used by the clients.
IMO latestSupportedProtocolVersion reflects only the initial state. After the re-initialization (once we implement this) the version can be downgraded to match server's perferences.
|
|
||
| private final List<String> supportedProtocolVersions; | ||
|
|
||
| private final String latestSupportedProtocolVersion; |
There was a problem hiding this comment.
Perhaps we should call this selectedProtocolVersion or negotiatedProtocolVersion.
After we implement the negotiation this value can change if the server request a lower version.
There was a problem hiding this comment.
The negotiated protocol version is not a property of the transport itself. I think it will be a property of the io.modelcontextprotocol.client.LifecycleInitializer.Initialization, and we'll pass it through the reactor context.
There was a problem hiding this comment.
i guess you are right. Anyway will think about this when we start the work. Will mere the PR as it is
The SDK does not support full version negotiation. However, for compatibility reasons, we want to make our client transports configurable so that users can set the range of "acceptable" spec versions