Giving this a little more thought, I imagine sending to a topic is the most common case, so maybe it's an overload worth having. Also, if `SendTarget` is just a marker interface, we could let `TopicPartition` implement it directly. Then we have:
interface SendTarget; class TopicPartition implements SendTarget; CompletionStage<RecordMetadata> send(String topic, Record record); CompletionStage<RecordMetadata> send(SendTarget target, Record record); The `SendTarget` would give us a lot of flexibility in the future. It would give us a couple options for topic ids. We could either have an overload of `send` which accepts `Uuid`, or we could add a `TopicId` type which implements `SendTarget`. -Jason On Sat, Jan 30, 2021 at 1:11 PM Jason Gustafson <ja...@confluent.io> wrote: > Yeah, good question. I guess we always tend to regret using lower-level > types in these APIs. Perhaps there should be some kind of interface: > > interface SendTarget > class TopicIdTarget implements SendTarget > class TopicTarget implements SendTarget > class TopicPartitionTarget implements SendTarget > > Then we just have: > > CompletionStage<RecordMetadata> send(SendTarget target, Record record); > > Not sure if we could reuse `Record` in the consumer though. We do have > some state in `ConsumerRecord` which is not present in `ProducerRecord` > (e.g. offset). Perhaps we could provide a `Record` view from > `ConsumerRecord` for convenience. That would be useful for use cases which > involve reading from one topic and writing to another. > > -Jason > > On Sat, Jan 30, 2021 at 12:29 PM Ismael Juma <ism...@juma.me.uk> wrote: > >> Interesting idea. A couple of things to consider: >> >> 1. Would we introduce the Message concept to the Consumer too? I think >> that's what .NET does. >> 2. If we eventually allow a send to a topic id instead of topic name, >> would >> that result in two additional overloads? >> >> Ismael >> >> On Sat, Jan 30, 2021 at 11:38 AM Jason Gustafson <ja...@confluent.io> >> wrote: >> >> > For the sake of having another option to shoot down, we could take a >> page >> > from the .net client and separate the message data from the destination >> > (i.e. topic or partition). This would get around the need to use a new >> > verb. For example: >> > >> > CompletionStage<RecordMetadata> send(String topic, Message message); >> > CompletionStage<RecordMetadata> send(TopicPartition topicPartition, >> Message >> > message); >> > >> > -Jason >> > >> > >> > >> > On Sat, Jan 30, 2021 at 11:30 AM 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 >> > >> > > > >> > >> > > > >> > >> > > >> > >> > >> > >> >> > > >> > >> >
