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 wi
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 either
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
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 obtru
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 1
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 t
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
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
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 dis
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 u
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/
11 matches
Mail list logo