lhotari opened a new issue, #10: URL: https://github.com/apache/pulsar-client-reactive/issues/10
In Micronaut, there's a good example of this. HttpClient https://docs.micronaut.io/latest/api/io/micronaut/http/client/HttpClient.html ReactorHttpClient extends HttpClient: https://micronaut-projects.github.io/micronaut-reactor/latest/api/io/micronaut/reactor/http/client/ReactorHttpClient.html With pulsar-client-reactive, the challenge is about the nested interface layers and how to make that seamlessly work. One possibility would be to have an interface method that adapts the current instance to some other Reactive Streams implementation library type. One option would be that it's completely decoupled from the Reactive Streams library implementation type ```java public interface ReactiveMessageSender<T> { Publisher<MessageId> sendMessages(Publisher<MessageSpec<T>> messageSpecs); <R> R adapt(Class<R> adaptedSenderType); } ``` ```java public interface ReactorMessageSender<T> { Mono<MessageId> sendMessage(Mono<MessageSpec<T>> messageSpec); Flux<MessageId> sendMessages(Flux<MessageSpec<T>> messageSpecs); } ``` Internally there would be some SPI (Service Provider Interface) which Reactive Streams library support modules could implement. This way it would be easy to add support for various Reactive Streams implementation libraries where the types of the implementation library would be directly supported. -- 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]
