Hi Ismael, Thanks for looking at the KIP and explaining the thinking behind the original API.
Looking at the updated KIP, I notice that we actually have a > TopicDeletionPolicy with a separate config. That seems to be a halfway > house. Not sure about that. > I can certainly see that point of view. I wasn't too happy with trying to shoehorn deletion in with creation and alteration though. It seems to me that the request metadata are different. One alternative would be to have a single policy interface (TopicManagementPolicy) with different methods for the create/alter and delete cases, with the delete having a different request metadata type. Since Java 7 is no longer supported we could have a different policy method per request. Using default interface methods means that adding new policy methods wouldn't be a breaking change. That said I still think having a common method for topic creation and alteration makes more sense: It forces the implementer of the interface to consider both cases at the same time. 1. "If this KIP is accepted for Kafka 1.1.0 this removal could happen in > Kafka 1.2.0 or a later release." -> we only remove code in major releases. > So, if it's deprecated in 1.1.0, it would be removed in 2.0.0. > Yes, sorry, seems I've managed to misunderstand the policy again. It would be really helpful if the policy were written down somewhere (though I realise that since 1.0.0 is not out we might not want to publish it yet). Anyway, I'll update the KIP. 2. Deleting all messages in a topic is not really the same as deleting a > topic. The latter will cause consumers and producers to error out while the > former will not. It would be good to motivate the need for the delete > records policy more. > I realise they're not the exactly the same, but in the end it's the messages which have value to the business running a cluster and the policy around losing those messages is likely to be the same which ever way they might be deleted. Thanks again, Tom
