You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Mason Chen <ma...@gmail.com> on 2022/08/11 08:20:13 UTC
[Discuss] KafkaSink making low level components PublicEvolving
Hi devs and community,
I would like to discuss making the low level components of the KafkaSink
PublicEvolving. It looks like all of the classes are package private apart
from the public facing API and classes were put in the same package to make
this work. My desire to make at least the KafkaSinkWriter a public class,
with no further changes to private/package-private methods. The class(es)
would be annotated with PublicEvolving.
I am in the process of implementing my own Sink that writes to Kafka and I
want to implement the SinkWriter by composing the functionality contained
in the KafkaSinkWriter. There is significant work in this implementation
and I would like to use it and contribute back, bug fixes for example, if I
find any in independent testing.
Hopefully, that motivates the request. Please let me know your thoughts!
Best,
Mason
Re: [Discuss] KafkaSink making low level components PublicEvolving
Posted by Piotr Nowojski <pn...@apache.org>.
Hi Mason,
Thanks for the clarification and great that you have found a workaround :)
I would be personally ok with making it `public class` marked as
`@Internal` if needed.
Best,
Piotrek
śr., 31 sie 2022 o 01:35 Mason Chen <ma...@gmail.com> napisał(a):
> Hi Piotr,
>
> The reasoning makes sense to me. I probably meant to say `public` class
> visibility and `@Internal` in my proposal, similar to other
> connector interface components (e.g. KafkaSourceReader).
>
> However, I actually found a workaround using the Public API sink builder
> and factory classes to create the sink writer, so I will abandon this
> effort for now until it would be required. Thanks for the feedback!
>
> Best,
> Mason
>
> On Tue, Aug 30, 2022 at 7:00 AM Piotr Nowojski <pn...@apache.org>
> wrote:
>
> > Hi Mason,
> >
> > I would be against making them part of the Public API. It would be
> against
> > our current conventions and it would make future changes in this
> connector
> > much more difficult. It's difficult to support Public APIs, even if they
> > are `@PublicEvolving`.
> >
> > Best,
> > Piotrek
> >
> > pon., 29 sie 2022 o 19:17 Mason Chen <ma...@gmail.com>
> napisał(a):
> >
> > > Hi all,
> > >
> > > I know everyone is busy with preparing the 1.16 release. Just want to
> > give
> > > this thread a gentle ping, please give your +1 if there are no
> concerns!
> > >
> > > Best,
> > > Mason
> > >
> > > On Thu, Aug 11, 2022 at 1:27 AM Mason Chen <ma...@gmail.com>
> > wrote:
> > >
> > > > I understand that the 1.16 feature freeze is in place so I propose
> for
> > > > these changes to go in the 1.17 release.
> > > >
> > > > Best,
> > > > Mason
> > > >
> > > > On Thu, Aug 11, 2022 at 1:20 AM Mason Chen <ma...@gmail.com>
> > > wrote:
> > > >
> > > >> Hi devs and community,
> > > >>
> > > >> I would like to discuss making the low level components of the
> > KafkaSink
> > > >> PublicEvolving. It looks like all of the classes are package private
> > > apart
> > > >> from the public facing API and classes were put in the same package
> to
> > > make
> > > >> this work. My desire to make at least the KafkaSinkWriter a public
> > > class,
> > > >> with no further changes to private/package-private methods. The
> > > class(es)
> > > >> would be annotated with PublicEvolving.
> > > >>
> > > >> I am in the process of implementing my own Sink that writes to Kafka
> > and
> > > >> I want to implement the SinkWriter by composing the functionality
> > > contained
> > > >> in the KafkaSinkWriter. There is significant work in this
> > implementation
> > > >> and I would like to use it and contribute back, bug fixes for
> example,
> > > if I
> > > >> find any in independent testing.
> > > >>
> > > >> Hopefully, that motivates the request. Please let me know your
> > thoughts!
> > > >>
> > > >> Best,
> > > >> Mason
> > > >>
> > > >
> > >
> >
>
Re: [Discuss] KafkaSink making low level components PublicEvolving
Posted by Mason Chen <ma...@gmail.com>.
Hi Piotr,
The reasoning makes sense to me. I probably meant to say `public` class
visibility and `@Internal` in my proposal, similar to other
connector interface components (e.g. KafkaSourceReader).
However, I actually found a workaround using the Public API sink builder
and factory classes to create the sink writer, so I will abandon this
effort for now until it would be required. Thanks for the feedback!
Best,
Mason
On Tue, Aug 30, 2022 at 7:00 AM Piotr Nowojski <pn...@apache.org> wrote:
> Hi Mason,
>
> I would be against making them part of the Public API. It would be against
> our current conventions and it would make future changes in this connector
> much more difficult. It's difficult to support Public APIs, even if they
> are `@PublicEvolving`.
>
> Best,
> Piotrek
>
> pon., 29 sie 2022 o 19:17 Mason Chen <ma...@gmail.com> napisał(a):
>
> > Hi all,
> >
> > I know everyone is busy with preparing the 1.16 release. Just want to
> give
> > this thread a gentle ping, please give your +1 if there are no concerns!
> >
> > Best,
> > Mason
> >
> > On Thu, Aug 11, 2022 at 1:27 AM Mason Chen <ma...@gmail.com>
> wrote:
> >
> > > I understand that the 1.16 feature freeze is in place so I propose for
> > > these changes to go in the 1.17 release.
> > >
> > > Best,
> > > Mason
> > >
> > > On Thu, Aug 11, 2022 at 1:20 AM Mason Chen <ma...@gmail.com>
> > wrote:
> > >
> > >> Hi devs and community,
> > >>
> > >> I would like to discuss making the low level components of the
> KafkaSink
> > >> PublicEvolving. It looks like all of the classes are package private
> > apart
> > >> from the public facing API and classes were put in the same package to
> > make
> > >> this work. My desire to make at least the KafkaSinkWriter a public
> > class,
> > >> with no further changes to private/package-private methods. The
> > class(es)
> > >> would be annotated with PublicEvolving.
> > >>
> > >> I am in the process of implementing my own Sink that writes to Kafka
> and
> > >> I want to implement the SinkWriter by composing the functionality
> > contained
> > >> in the KafkaSinkWriter. There is significant work in this
> implementation
> > >> and I would like to use it and contribute back, bug fixes for example,
> > if I
> > >> find any in independent testing.
> > >>
> > >> Hopefully, that motivates the request. Please let me know your
> thoughts!
> > >>
> > >> Best,
> > >> Mason
> > >>
> > >
> >
>
Re: [Discuss] KafkaSink making low level components PublicEvolving
Posted by Piotr Nowojski <pn...@apache.org>.
Hi Mason,
I would be against making them part of the Public API. It would be against
our current conventions and it would make future changes in this connector
much more difficult. It's difficult to support Public APIs, even if they
are `@PublicEvolving`.
Best,
Piotrek
pon., 29 sie 2022 o 19:17 Mason Chen <ma...@gmail.com> napisał(a):
> Hi all,
>
> I know everyone is busy with preparing the 1.16 release. Just want to give
> this thread a gentle ping, please give your +1 if there are no concerns!
>
> Best,
> Mason
>
> On Thu, Aug 11, 2022 at 1:27 AM Mason Chen <ma...@gmail.com> wrote:
>
> > I understand that the 1.16 feature freeze is in place so I propose for
> > these changes to go in the 1.17 release.
> >
> > Best,
> > Mason
> >
> > On Thu, Aug 11, 2022 at 1:20 AM Mason Chen <ma...@gmail.com>
> wrote:
> >
> >> Hi devs and community,
> >>
> >> I would like to discuss making the low level components of the KafkaSink
> >> PublicEvolving. It looks like all of the classes are package private
> apart
> >> from the public facing API and classes were put in the same package to
> make
> >> this work. My desire to make at least the KafkaSinkWriter a public
> class,
> >> with no further changes to private/package-private methods. The
> class(es)
> >> would be annotated with PublicEvolving.
> >>
> >> I am in the process of implementing my own Sink that writes to Kafka and
> >> I want to implement the SinkWriter by composing the functionality
> contained
> >> in the KafkaSinkWriter. There is significant work in this implementation
> >> and I would like to use it and contribute back, bug fixes for example,
> if I
> >> find any in independent testing.
> >>
> >> Hopefully, that motivates the request. Please let me know your thoughts!
> >>
> >> Best,
> >> Mason
> >>
> >
>
Re: [Discuss] KafkaSink making low level components PublicEvolving
Posted by Mason Chen <ma...@gmail.com>.
Hi all,
I know everyone is busy with preparing the 1.16 release. Just want to give
this thread a gentle ping, please give your +1 if there are no concerns!
Best,
Mason
On Thu, Aug 11, 2022 at 1:27 AM Mason Chen <ma...@gmail.com> wrote:
> I understand that the 1.16 feature freeze is in place so I propose for
> these changes to go in the 1.17 release.
>
> Best,
> Mason
>
> On Thu, Aug 11, 2022 at 1:20 AM Mason Chen <ma...@gmail.com> wrote:
>
>> Hi devs and community,
>>
>> I would like to discuss making the low level components of the KafkaSink
>> PublicEvolving. It looks like all of the classes are package private apart
>> from the public facing API and classes were put in the same package to make
>> this work. My desire to make at least the KafkaSinkWriter a public class,
>> with no further changes to private/package-private methods. The class(es)
>> would be annotated with PublicEvolving.
>>
>> I am in the process of implementing my own Sink that writes to Kafka and
>> I want to implement the SinkWriter by composing the functionality contained
>> in the KafkaSinkWriter. There is significant work in this implementation
>> and I would like to use it and contribute back, bug fixes for example, if I
>> find any in independent testing.
>>
>> Hopefully, that motivates the request. Please let me know your thoughts!
>>
>> Best,
>> Mason
>>
>
Re: [Discuss] KafkaSink making low level components PublicEvolving
Posted by Mason Chen <ma...@gmail.com>.
I understand that the 1.16 feature freeze is in place so I propose for
these changes to go in the 1.17 release.
Best,
Mason
On Thu, Aug 11, 2022 at 1:20 AM Mason Chen <ma...@gmail.com> wrote:
> Hi devs and community,
>
> I would like to discuss making the low level components of the KafkaSink
> PublicEvolving. It looks like all of the classes are package private apart
> from the public facing API and classes were put in the same package to make
> this work. My desire to make at least the KafkaSinkWriter a public class,
> with no further changes to private/package-private methods. The class(es)
> would be annotated with PublicEvolving.
>
> I am in the process of implementing my own Sink that writes to Kafka and I
> want to implement the SinkWriter by composing the functionality contained
> in the KafkaSinkWriter. There is significant work in this implementation
> and I would like to use it and contribute back, bug fixes for example, if I
> find any in independent testing.
>
> Hopefully, that motivates the request. Please let me know your thoughts!
>
> Best,
> Mason
>