Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-25 Thread Ismael Juma
Thanks Tom, looks reasonable to me. I'll take a closer look soon, but please go ahead with the vote whenever you're ready. Ismael On Thu, Mar 25, 2021, 8:53 AM Tom Bentley wrote: > Hi, > > I've updated the KIP along the lines of my previous reply to Ismael. If no > one has further comments I

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-25 Thread Tom Bentley
Hi, I've updated the KIP along the lines of my previous reply to Ismael. If no one has further comments I will likely start a vote thread next week. Kind regards, Tom On Tue, Mar 23, 2021 at 10:01 AM Tom Bentley wrote: > Hi Ryanne, > > Thanks for the reply. If there was a consensus for

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-23 Thread Tom Bentley
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

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-23 Thread Tom Bentley
Hi Ismael, Thanks for the reply. So this is what's described in the KIP but using CompletionStage rather than CompletableFuture, right? And I assume the methods of concern are complete(), and completeExceptionally(), which only the Admin client should be calling, and also obtrudeValue() and

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-23 Thread Tom Bentley
Hi Viktor, Thanks for the reply. It would not be possible for KafkaFuture to subclass CompletableFuture in a compatible way, as described (for CompletionStage, but the argument holds) in [1]. Kind regards, Tom [1]: https://github.com/apache/kafka/pull/9878#issuecomment-762955770 On Fri, Mar

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-19 Thread Ryanne Dolan
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 wrote: > I've previously discounted the possibility of an "Admin2" client, but > seeing

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-19 Thread Ismael Juma
Hi Tom, I think it makes sense to go with the incremental option. I don't like CompletableFuture because it exposes a bunch of unsafe methods. Since we're adding this to `KafkaFuture`, then methods like `get` are already available. What benefit is there for exposing `CompletableFuture` instead of

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-03-19 Thread Viktor Somogyi-Vass
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 wrote: > If the next release is going to be Kafka 3.0, as seems to be the case, it > would be a great time

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-02-24 Thread Tom Bentley
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 wrote: > I've previously

Re: [DISCUSS] KIP-707: The future of KafkaFuture

2021-02-02 Thread Tom Bentley
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

[DISCUSS] KIP-707: The future of KafkaFuture

2021-01-22 Thread Tom Bentley
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.