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
>

Reply via email to