hi Colin the interface `ClientQuotaCallackHandler` is a typo - the idea of this PR is to add new `updateClusterMetadata` to replace/deprecate old `updateClusterMetadata`. Additionally, the production code will call new `updateClusterMetadata` instead of old `updateClusterMetadata`. That means users who to want migrate to new `updateClusterMetadata` should make old `updateClusterMetadata` throw exception and implement new `updateClusterMetadata`. For example:
``` MyCallback implements ClientQuotaCallback { boolean updateClusterMetadata(Cluster cluster) { throw new UnsupportException(); } override boolean updateClusterMetadata(ClusterMetadata clusterMetadata) { // new implementation } } ``` Should we instead have a new interface (which can inherit from the old interface, for now)? Yes, we had discussed this approach. We can dynamically create the object based on the new interface first, and then try the old interface for users who are still using it. Additionally, a callback implementing the old interface can be wrapped to conform to the new interface. However, this still exposes the "deprecated" method/structure to users, even as they are migrating to the new interface. A more direct approach is to have the new interface *not* extend the old one. This ensures that users will definitely not interact with the old structure when using the new interface. Of course, wrapping will still be necessary. This approach was used when migrating the public APIs of tools from Scala to Java (KIP-641). Best, Chia-Ping Colin McCabe <cmcc...@apache.org> 於 2025年4月29日 週二 上午4:38寫道: > Hi Kuan Po Tseng, > > Thank you for starting this discussion. This would be a very nice > improvement. > > It seems that the current scheme requires everyone writing an > implementation of ClientQuotaCallackHandler to implement the old > updateClusterMetadata function that takes a Cluster. That seems less than > ideal, since once we remove that deprecated function, it will break > compilation for anyone implementing it. Should we instead have a new > interface (which can inherit from the old interface, for now)? That would > avoid this issue... > > best, > Colin > > > On Tue, Apr 22, 2025, at 09:23, Kuan Po Tseng wrote: > > Hello everyone, > > > > I’d like to kick off a discussion about redesigning > > ClientQuotaCallback#updateClusterMetadata. > > As it stands, the current implementation is quite inefficient, since it > > requires creating > > a full Cluster object each time any change is made. On top of that, some > of > > the information > > within the Cluster object is outdated. > > > > With that in mind, I’d love to propose a lighter, more efficient > solution, > > along with a redefined > > interface for the object passed into updateClusterMetadata. If you have a > > moment, I’d really appreciate your thoughts and feedback on this. > > > > Thank you! > > > > KIP link: https://cwiki.apache.org/confluence/x/zInoF > > > > Best, > > Kuan-Po Tseng >