Skip to content

Conversation

@brasseld
Copy link

This PR is a proposal to make the transport configuration specific to a given transport implementation.

This one will ease developer experience by providing a builder for configuring a Client in a more stricter way compare to what exists today.

Also, this will help at getting rid of strong coupling with different transport implementations.
Two benefits:

  • Get rid of dependencies which may not be required (grpc dependencies if you only go for jsonrpc)
  • Easier to provide new transport implementation (such as HTTP+JSON).

misselvexu and others added 30 commits August 20, 2025 16:20
… and also split out the http client code into a separate module
…text, ClientConfig, and ClientCallInterceptor similar to the Python SDK. Introduce a ClientTransportProvider and update the JSONRPC and gRPC transport implementations. Introduce a new Client and ClientFactory implementations.
… to make use of it, and remove the http-client and grpc dependencies from the client config module
…t to be able to make use of the appropriate client based on the transport and update the JSONRPC and gRPC tests to extend this
…d some convenience methods to AbstractClient
…t other server implementations that also support JSONRPC can make use of these tests. These tests will be skipped when testing other transports
…text, ClientConfig, and ClientCallInterceptor similar to the Python SDK. Introduce a ClientTransportProvider and update the JSONRPC and gRPC transport implementations. Introduce a new Client and ClientFactory implementations.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants