a pretty small thing to do
> > and it probably doesn't preclude someone coming along with a
> > Kafka data model in the future.
> >
> > Just my 2 cents.
> >
> > Thanks,
> > Andrew
> >
> > From: Mario
thing to do
> and it probably doesn't preclude someone coming along with a
> Kafka data model in the future.
>
> Just my 2 cents.
>
> Thanks,
> Andrew
> ________________________
> From: Mario Fiore Vitale
> Sent: 17 January 2025 11:20
> To:
Vitale
Sent: 17 January 2025 11:20
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1122: Create a dedicated data module for Kafka
Connect data classes
Hi all,
Any other feedback on this? I'll take the discussion open for another week
and then start the vote.
Thanks,
Mario.
On Fri,
Hi all,
Any other feedback on this? I'll take the discussion open for another week
and then start the vote.
Thanks,
Mario.
On Fri, Jan 10, 2025 at 10:30 AM Mario Fiore Vitale
wrote:
> Hi Greg, thanks for giving a look.
>
> > It's a closed type system which cannot have new "physical" types adde
Hi Greg, thanks for giving a look.
> It's a closed type system which cannot have new "physical" types added by
third-party developers
Do you have some examples for this? In my experience I never had the need
to add a new type.
> There are carve-outs in the implementation for framework logical ty
Hi Mario,
Thanks for the KIP! I think that using the same data model inside and
outside of connect is valuable, and is a good motivation for this effort.
However, I have seen many situations where the existing data model is
insufficient for Connect plugin developers.
* It's a closed type system w
Hi all,
I just want to bring the discussion up since it was open during the
Christmas holidays.
Any other considerations?
Thanks,
Mario.
On Sat, Dec 28, 2024 at 3:04 PM Mario Fiore Vitale
wrote:
> Hey Hector,
>
> the aim of this KIP is to separate the Connect data (Struct, Schema, etc.)
> so
Hey Hector,
the aim of this KIP is to separate the Connect data (Struct, Schema, etc.)
so it can be used without having a dependency con connect-api.
So the proposal is more related to economics.
As Kafka itself became an API during the years, maybe also the Connect data
can be used as a general
Hey Mario,
From a quick read of this KIP, it's not super clear to me what problem it is
trying to solve. The motivation states that "current implementation restricts
the usage of data classes", and I'm not sure what you mean by that.
Can you maybe add one or two examples of things that are not
