lhotari commented on PR #11: URL: https://github.com/apache/pulsar-client-reactive/pull/11#issuecomment-1291940991
> You rather call buildReactor or buildRxJava on the builder. I don't see how it's less discoverable than having to do adapt(ReactorMessageSender.class) In the case of using 2) solution described in https://github.com/apache/pulsar-client-reactive/pull/11#pullrequestreview-1155947293 , there would be no need to call adapt. We have lost it already if there's ever methods like `buildReactor` or `buildRxJava` on the API. I'm pretty sure that by iterating on this, there's a model which will make sense. In the comment in https://github.com/apache/pulsar-client-reactive/pull/11#pullrequestreview-1155947293, I'm stating that there's 2 main possibilities: to stick with Project Reactor as the main implementation and provide the adapt path for others or having a complete API structure that is already split at the ReactivePulsarClient level. Let's keep on iterating until there's a proper solution. > We don't know how to build the adaptedReaderType instance. There's no contract for it. Maybe could have an implicit contract where we call the constructor with the this as parameter. Something like This is a solvable problem. In #10 description, I referenced "Service Provider Interface", SPI. There could be an interface that that should be implemented to add support for an RS library. I understand that it's not the type erasure issue that you referenced. That's a bit more challenging problem, but there are solutions to that too. -- 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]
