Hi Kirk
Many thanks for very good questions!

KT1. I don't think that internal implementation should totally prevent of
passing alternative implementation, but for sure we need to log warning
when producer receives different than default implementaion. I think that
checking internally is the class implementation exactly
DefaultConsumerGroupMetadata  is against some basic principles like liskov
substition and if we like to design this mechanism that way, we shouldn't
expose an interface.
KT2. I am also not 100% satisfied with that name, I don't think that there
will be need for future different implementations as it is simple data
struct.
KT3. It will be place in producer/internals package and default java scope
for constructor and whole class.

@Matthias J. Sax <mj...@apache.org> having those KT1 and KT2 in mind,
should we move forward with an interface or maybe ConsumerGroupMetadata has
to be a class, but we have to  limit possibility to create an instance
manualy by making the class final and changing constructor visibility to
private or package scope?

czw., 27 lut 2025 o 01:51 Kirk True <k...@kirktrue.pro> napisał(a):

> Hi Paweł,
>
> Thanks for the KIP!
>
> My questions:
>
> KT1. What will prevent developers from implementing their own
> ConsumerGroupMetadata and passing that to sendOffsetsToTransaction()? I
> assume the code will check the incoming object is of type
> DefaultConsumerGroupMetadata?
>
> KT2. To me, the use of the adjective "default" in
> DefaultConsumerGroupMetadata implies that there could be other
> implementations. Is the intention that there could be other implementations
> in the future?
>
> KT3. DefaultConsumerGroupMetadata should be defined in an "internals"
> package of some sort, right? Will users ever reference the implementation
> class name in their code? I'm assuming not.
>
> Thanks!
> Kirk
>
> On Tue, Feb 25, 2025, at 8:24 AM, Paweł Szymczyk wrote:
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1136%3A+Make+ConsumerGroupMetadata+an+interface
> >
> > --
> > Pozdrawiam
> > Paweł Szymczyk
> >
>


-- 
Pozdrawiam
Paweł Szymczyk

Reply via email to