Hi all, I'm looking at the original Jira that introduced these stability designations [1] and I'm just curious if it was intended that these Internal classes would be used directly, or if we just haven't created the right abstractions? The reason for asking is because moving something from Internal to a public designation is an easy fix, but I want to make sure that it's also the right fix. If we are missing good abstractions, then I would rather invest in those.
Best regards, Martijn [1] https://issues.apache.org/jira/browse/FLINK-22358 On Wed, Nov 8, 2023 at 12:40 PM Leonard Xu <xbjt...@gmail.com> wrote: > > Thanks Hongshun for starting this discussion. > > +1 from my side. > > IIRC, @Jiangjie(Becket) also mentioned this in FLINK-31324 comment[1]. > > Best, > Leonard > > [1] > https://issues.apache.org/jira/browse/FLINK-31324?focusedCommentId=17696756&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17696756 > > > > > 2023年11月8日 下午5:42，Hongshun Wang <loserwang1...@gmail.com> 写道： > > > > Hi devs, > > > > I would like to start a discussion on FLIP-389: Annotate > > SingleThreadFetcherManager and FutureCompletingBlockingQueue as > > PublicEvolving.[ > > <https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278465498> > > 1]. > > > > Though the SingleThreadFetcherManager is annotated as Internal, it actually > > acts as some-degree public API, which is widely used in many connector > > projects: flink-cdc-connector > > <https://github.com/ververica/flink-cdc-connectors/blob/release-2.3.0/flink-connector-mysql-cdc/src/main/java/com/ververica/cdc/connectors/mysql/source/reader/MySqlSourceReader.java#L93> > > , flink-connector-mongodb > > <https://github.com/apache/flink-connector-mongodb/blob/main/flink-connector-mongodb/src/main/java/org/apache/flink/connector/mongodb/source/reader/MongoSourceReader.java#L58> > > and > > soon. > > > > Moreover, even the constructor of SingleThreadMultiplexSourceReaderBase > > (which is PublicEvolving) includes the params of SingleThreadFetcherManager > > and FutureCompletingBlockingQueue. That means that the > > SingleThreadFetcherManager and FutureCompletingBlockingQueue have already > > been exposed to users for a long time and are widely used. > > > > Considering that all source implementations are using them de facto, why > > not annotate SingleThreadFetcherManager and FutureCompletingBlockingQueue > > as PublicEvolving so that developers will modify it more carefully to avoid > > any potential issues. As shown in FLINK-31324[2], FLINK-28853[3] used > > to change the default constructor of SingleThreadFetcherManager. However, > > it influenced a lot. Finally, the former constructor was added back and > > marked as Deprecated。 > > > > In conclusion, the goal of this FLIP is to annotate > > SingleThreadFetcherManager(includes its parent class) and > > FutureCompletingBlockingQueue as PublicEvolving. > > > > Looking forward to hearing from you. > > > > > > [1] > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278465498 > > > > [2] https://issues.apache.org/jira/browse/FLINK-31324 > > > > [3] https://issues.apache.org/jira/browse/FLINK-28853 >
