vax-r opened a new pull request, #1912:
URL: https://github.com/apache/iggy/pull/1912
## Summary
This PR aims to refactor the usage of `dyn Client` to `T: Client`.
This is still a broken solution, the basis are almost done as in the
commits. Currently the way to use it will be the main problem, as you can see
in benchmarks and integration tests. When using `dyn Client` , it grants us the
convenience to implement single function to adapt numerous client type. Now
switching to `IggyClient<T: Client>`, `IggyConsumer<T: Client>` , we need to
put the type in explicitly, e.g. `IggyClient::<HttpClient>` , so it's hard to
single function to be used to form a complete test.
Main difficulties are listed below, maybe we should discuss before
proceeding.
* For `ClientFactory::create_client()` , it's given an user-specific config
and the program will figure out which protocol it is using. Now we must figure
out the type of protocol first and call `create_client::<protocol_type>` so it
can return a concrete type e.g. `IggyClient<TcpClient>` rather than `Box<dyn
Client>`.
- This change kinda breaks the intention of `create_client()` from my
point of view, cuz SDK can't assume what protocol it will get from user.
- Implement function like `create_tcp_client()` and so on doesn't help
us get through the issue listed above, looks like when we can't assume the
actual type of `T: Client` in advance, we need `dyn Client` ?
* `get_raw_client()` and its related helpers suffers the same issue, we can
get around this with `unsafe` Rust. However, when using it in actual cases, we
need to find a way to give concrete type for `T` , check the case in
`core/tools/src/data-seeder/main.rs`
* Test cases will need to be modified to a high degree, e.g. the case for
`create_client()` , `get_raw_client()`. Might even be separated as cases for
http, quic, tcp and mixtures of them. Not sure if this is wanted.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
