> > Furthermore, we should align with the longer term plan for the AdminClient > that returns KafkaFuture today. >
I've sketched a few ideas about that in KIP-707 and its discussion thread, if people want to share their thoughts. On Sun, Jan 31, 2021 at 5:51 AM Chia-Ping Tsai <chia7...@apache.org> wrote: > Fair enough. I will isolate KIP-706 later. > > On 2021/01/30 20:18:42 Ismael Juma wrote: > > I agree with Jason and would rather tackle this as one KIP and the error > > handling in another. The error handling can follow this one once we agree > > on the method signatures. Furthermore, we should align with the longer > term > > plan for the AdminClient that returns KafkaFuture today. > > > > Ismael > > > > On Sat, Jan 30, 2021 at 11:40 AM Chia-Ping Tsai <chia7...@apache.org> > wrote: > > > > > I'd like to merge KIP-706 to KIP-691 as it can bring a comprehensive > > > design for both new API and exception. The new exception should be > included > > > by the new API also. > > > > > > On 2021/01/30 19:30:40, Jason Gustafson <ja...@confluent.io> wrote: > > > > I think this still makes sense as a separate KIP. For KIP-691, we are > > > just > > > > looking to help define the error contract for the new API. > > > > > > > > -Jason > > > > > > > > On Sat, Jan 30, 2021 at 8:39 AM Ismael Juma <ism...@juma.me.uk> > wrote: > > > > > > > > > Are we saying that we won't pursue this KIP in favor of the other > one? > > > > > > > > > > Ismael > > > > > > > > > > On Sat, Jan 30, 2021, 4:15 AM Chia-Ping Tsai <chia7...@apache.org> > > > wrote: > > > > > > > > > > > hi Jason > > > > > > > > > > > > Thanks for your response. "transmit" is good to me. > > > > > > > > > > > > As we discussed by email, KIP-706 is going to be merged to > KIP-691( > > > > > > https://cwiki.apache.org/confluence/x/PSfZCQ). Hence, please > feel > > > free > > > > > to > > > > > > replace "produce" by "transmit" in KIP-691. > > > > > > > > > > > > Best, > > > > > > Chia-Ping > > > > > > > > > > > > On 2021/01/30 00:48:38, Jason Gustafson <ja...@confluent.io> > wrote: > > > > > > > Hi Chia-Ping, > > > > > > > > > > > > > > I think this is a great idea. It is a pity that we cannot > continue > > > to > > > > > use > > > > > > > the `send` verb, but I don't see how we can. I know we > considered > > > > > > > `transmit` as another option which is closer to `send`. That > would > > > > > avoid > > > > > > > the redundancy when people choose the common "producer" > variable > > > name. > > > > > > > > > > > > > > producer.transmit > > > > > > > > > > > > > > instead of > > > > > > > > > > > > > > producer.produce > > > > > > > > > > > > > > A couple alternatives might be `write` or `append`. I'm happy > with > > > > > > > `produce` as well, but curious if others have thoughts. > > > > > > > > > > > > > > -Jason > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 20, 2021 at 9:37 AM Chia-Ping Tsai < > > > chia7...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > I'd like to start the discussion thread for KIP-706: > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=100829459 > > > > > > > > > > > > > > > > KIP-706 is proposing to introduce new API "CompletionStage > > > > > > > > produce(record)" to Producer. Kafka users can leverage > > > > > CompletionStage > > > > > > to > > > > > > > > write asynchronous non-blocking code. CompletionStage is more > > > > > powerful > > > > > > than > > > > > > > > Future and callback. Also, the code using Future and callback > > > can be > > > > > > easily > > > > > > > > re-written by CompletionStage. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Chia-Ping > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
