bq. topic.action.policy.class.name Since the policy would cover more than one action, how about using actions for the second word ?
For TopicState interface, the abstract modifier for its methods are not needed. bq. KIP-113 Mind adding more to the above bullet ? bq. If this KIP is accepted for Kafka 1.1.0 this removal could happen in Kafka 3.0.0 There would be no Kafka 2.0 ? Cheers On Mon, Sep 25, 2017 at 3:34 AM, Tom Bentley <t.j.bent...@gmail.com> wrote: > Hi, > > I'd like to start a discussion for KIP-201. The basic point is that new > AdminClient APIs for modifying topics should have a configurable policy to > allow the administrator to veto the modifications. Just adding a > ModifyTopicPolicy would make for awkwardness by having separate policies > for creation and modification, so the KIP proposes unifying both of these > under a single new policy. > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 201%3A+Rationalising+Policy+interfaces > > Cheers, > > Tom >
