Hi Colin, Thanks for the KIP, great to make progress on this. I have some initial comments, will post more later:
1. We have KafkaProducer that implements the Producer interface and KafkaConsumer that implements the Consumer interface. Maybe we could have KafkaAdminClient that implements the AdminClient interface? Or maybe just KafkaAdmin. Not sure, some ideas for consideration. Also, I don't think we should worry about a name clash with the internal AdminClient written in Scala. That will go away soon enough and choosing a good name for the public class is what matters. 2. We should include the proposed package name in the KIP (probably org.apache.kafka.clients.admin?). 3. It would be good to list the supported configs. 4. KIP-107, which passed the vote, specifies the introduction of a method to AdminClient with the following signature. We should figure out how it would look given this proposal. Future<Map<TopicPartition, PurgeDataResult>> purgeDataBefore(Map<TopicPartition, Long> offsetForPartition) 5. I am not sure about rejecting the Futures-based API. I think I would prefer that, personally. Grant had an interesting idea of not exposing the batch methods in the AdminClient to start with to keep it simple and relying on a Future based API to make it easy for users to run things concurrently. This is consistent with the producer and Java 8 makes things a lot nicer with CompletableFuture (similar to Scala Futures). I will think more about this and other details of the proposal and send a follow-up. Ismael On Thu, Feb 2, 2017 at 6:54 PM, Colin McCabe <cmcc...@apache.org> wrote: > Hi all, > > I wrote up a Kafka improvement proposal for adding an > AdministrativeClient interface. This is a continuation of the work on > KIP-4 towards centralized administrative operations. Please check out > https://cwiki.apache.org/confluence/display/KAFKA/KIP-117%3A+Add+a+public+ > AdministrativeClient+API+for+Kafka+admin+operations > > regards, > Colin >
