Hi Tom, Have you considered to directly subclass CompletableFuture? Can we do this? Maybe a good addition to the alternatives.
Thanks, Viktor On Wed, Feb 24, 2021 at 10:13 AM Tom Bentley <tbent...@redhat.com> wrote: > If the next release is going to be Kafka 3.0, as seems to be the case, it > would be a great time to decide whether and what we're doing with this API. > So I'd be grateful for any feedback people might have. > > Many thanks, > > Tom > > On Tue, Feb 2, 2021 at 10:40 AM Tom Bentley <tbent...@redhat.com> wrote: > > > I've previously discounted the possibility of an "Admin2" client, but > > seeing the recent discussions on the thread for KIP-706, I wonder whether > > this current proposal in KIP-707 would benefit from a bit more > > discussion... I think there are broadly two approaches to evolving the > > Admin client API to use CompletionStage directly (rather than what's > > currently proposed in KIP-707): > > > > The simpler option, from a development point of view, would be to > > introduce an alternative/parallel set of classes for each of the existing > > result classes. E.g. ListTopicsOutcome which was the same as > > ListTopicsResult, but using CompletionStage rather than KafkaFuture. > Adding > > methods to the existing Admin interface would require coming up with > > synonym method names for every API call, and probably half of the API > being > > deprecated (if not immediately then in the long run). It would be cleaner > > to have a whole new interface, let's call it Manager, using the same > method > > names. The existing Admin client implementation would then wrap a Manager > > instance, and the existing Result classes could have a constructor > > parameter of their corresponding Outcome instance which wrapped the > > CompletionStages with KafkaFutures. The Options classes would be > unchanged. > > From a users point of view migrating to the new Manager client would > mostly > > be a matter of changing class names and adding a `.toCompletionStage()` > to > > those places where they were calling KafkaFuture.get()/getNow() (and even > > this could be avoided if we used CompletableFuture rather than > > CompletionStage in the Outcome class APIs). In the long run Admin would > be > > removed and we'd be left with the minor annoyance of having a client > called > > Manager in a package called admin. > > > > The more involved version would do a similar refactoring, but within a > > different package. If we stuck with the Admin and Result class names the > > users experience of migrating their codebase would be limited to changing > > import statements and the same additions of `.toCompletionStage()`. On > the > > implementation side it would force us to duplicate all the Options > classes > > and also have a way of converting old Options instances to their new > > equivalents so that the old Admin implementation could delegate to the > new > > one. The main benefit of this approach seems to be the slightly easier > > experience for people porting their code to the new client. > > > > In doing either of these much more significant refactorings there would > > also be the opportunity to omit the current Admin API's deprecated > methods > > and classes from the new API. > > > > Do we think this is worth biting off in order to have more long term > > consistency between the Admin, Producer and consumer APIs? > > > > Kind regards, > > > > Tom > > > > On Fri, Jan 22, 2021 at 3:02 PM Tom Bentley <tbent...@redhat.com> wrote: > > > >> Hi, > >> > >> Following a recent discussion on a PR[1], I've written KIP-707 to > >> establish what should be done to improve the API of KafkaFuture. > >> If you have the time, your comments would be most welcome, as some of > the > >> rejected alternatives are not unreasonable. > >> > >> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-707%3A+The+future+of+KafkaFuture > >> > >> Many thanks, > >> > >> Tom > >> > >> [1]: https://github.com/apache/kafka/pull/9878 > >> > > >
