I felt the same need when we want to add a pluggable API for core
server functionality. This does not need to be part of this KIP, it
can be a separate KIP. I can contribute those refactoring changes if
others are OK with that.

It is better to have a structure like below.

kafka-common:
common classes which can be used in any of the other modules in Kafka
like client, Kafka-server-common and server etc.

kafka-client-common:
common classes which can be used in the client module. This can be
part of client module itself.

kafka-server-common:
classes required only for kafka-server.

Thanks.
Satish.

On Wed, Aug 7, 2019 at 9:28 PM Harsha Chintalapani <ka...@harsha.io> wrote:
>
> Thanks for the KIP Rajini.
> Quick thought, it would be good to have a common module outside of clients
> that only applies to server side interfaces & changes. It looks like we are
> increasingly in favor of using Java interface for pluggable modules  on the
> broker side.
>
> Thanks,
> Harsha
>
>
> On Tue, Aug 06, 2019 at 2:31 PM, Rajini Sivaram <rajinisiva...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > I have created a KIP to replace the Scala Authorizer API with a new Java
> > API:
> >
> > -
> > https://cwiki.apache.org/confluence/display/KAFKA/
> > KIP-504+-+Add+new+Java+Authorizer+Interface
> >
> > This is replacement for KIP-50 which was accepted but never merged. Apart
> > from moving to a Java API consistent with other pluggable interfaces in the
> > broker, KIP-504 also attempts to address known limitations in the
> > authorizer. If you have come across other limitations that you would like
> > to see addressed in the new API, please raise these on the discussion
> > thread so that we can consider those too. All suggestions and feedback are
> > welcome.
> >
> > Thank you,
> >
> > Rajini
> >

Reply via email to