Hi Ryanne, Thanks for the reply. If there was a consensus for either of the more ambitious changes described in my 2nd email then I would agree with you, since it's much easier for users to understand and deal with and avoids having a situation of a class with half of its API deprecated, the need to find synonyms etc.
TBH though, that 2nd email was an attempt to get people thinking and engaging in the discussion. My personal preference is much closer to the incremental option described in the KIP, because overall I don't think there are nearly enough API mistakes/tech debt in the admin client overall to warrant such a big change. Sure, there are a few deprecated methods and classes, and using CompletionStage or CompletableFuture rather than KafkaFuture would require major changes where those could be cleaned up at the same time, but it just doesn't seem worth it when the vast majority of the API is fine. It would force everyone using the Admin client to eventually switch, whereas adding an accessor to KafkaFuture achieves the prime objective of enabling people who need to to interoperate with 3rd party APIs requiring CompletionStage, while requiring nothing of all the other users of the API. So unless there's a chorus of people who disagree and think that such a big refactoring really is worthwhile, then I'm inclined to stick with something closer to KIP-707. Many thanks, Tom On Fri, Mar 19, 2021 at 4:52 PM Ryanne Dolan <ryannedo...@gmail.com> wrote: > My two cents: keep the same method and class names and just use a different > package. Strongly dislike coming up with slightly different names for > everything. > > Ryanne > > On Tue, Feb 2, 2021, 4:41 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 > > > > > >
