Hi Chris, Thanks for the feedback. I updated the wrong Javadoc.
Any other comments from anybody? Thanks, Mario. Il giorno ven 23 gen 2026 alle ore 07:31 Chris Egerton < [email protected]> ha scritto: > Hi Mario, > > Thanks for the updates, especially the comprehensive compatibility section! > The KIP looks good to me, though you may want to double-check the example > Javadocs on ConnectRestExtension::config > and ConnectorClientConfigOverridePolicy::config :) > > Cheers, > > Chris > > On Thu, Jan 22, 2026 at 5:54 AM Mario Fiore Vitale via dev < > [email protected]> wrote: > > > Hi Chris, thanks for your valuable feedback! > > > > > 1. (Minor) The Javadoc for HeaderConverter::config is a little > > strange--is > > it meant to refer to "this set of header converters" or should it just be > > "this header converter"? > > > > This was just taken from the current source. But I agree that it should > be > > "this header converter". > > > > > For example, there's the obvious case > > where a plugin instantiates an object with a left-hand-type of > > ConfigSpecifier in its constructor. That plugin would be incompatible > with > > older versions of Connect. > > > > Do you have an example of this? As you said, it's unlikely that this > would > > occur in practice, also to me. > > > > > If a plugin explicitly > > implements ConfigSpecifier, would that break compatibility? > > > > In this case, it should. > > > > > If a plugin > > doesn't explicitly implement ConfigSpecifier, would that break > > compatibility? > > > > This should not break it. > > > > > These are the two cases that come to mind immediately but if > > any others occur to you feel free to document them as well. > > > > No other cases come to mind. I'll update the compatibility section with > the > > forward compatibility consideration. > > > > > There's also the pluggable ConnectRestExtension > > and ConnectorClientConfigOverridePolicy interfaces. Neither currently > > exposes a config method but it wouldn't be out of the question to add one > > now to them with a default implementation that returns an empty > ConfigDef. > > > > Well, I would say that since they are `Configurable`, I could expect that > > maybe in some future there could also be the possibility to declare a > > specific configuration. > > So your proposal to add it and implement it as a default seems good to > me. > > > > Regards, > > Mario. > > > > > > Il giorno gio 22 gen 2026 alle ore 04:33 Chris Egerton < > > [email protected]> ha scritto: > > > > > Hi Mario, > > > > > > Thanks for the KIP! My thoughts: > > > > > > 1. (Minor) The Javadoc for HeaderConverter::config is a little > > strange--is > > > it meant to refer to "this set of header converters" or should it just > be > > > "this header converter"? > > > > > > 2. The compatibility problem with Connect is always gnarly. The section > > on > > > backward compatibility is very well done in that it demonstrates with > > > certainty that older plugins will be able to run smoothly on newer > > versions > > > of the Connect runtime. However, there's also the question of whether > > newer > > > plugins (compiled against a future version of the Connect API with the > > > change proposed in this KIP) will continue to be compatible with older > > > versions of the Connect runtime. For example, there's the obvious case > > > where a plugin instantiates an object with a left-hand-type of > > > ConfigSpecifier in its constructor. That plugin would be incompatible > > with > > > older versions of Connect. It's unlikely that this would occur in > > practice > > > and even if it does, I think it's fine to accept that as a tradeoff. > > > However, it'd be nice to see the compatibility section explore exactly > > what > > > would render a plugin compiled against the newer Connect API > incompatible > > > with older versions of the Connect runtime. If a plugin explicitly > > > implements ConfigSpecifier, would that break compatibility? If a plugin > > > doesn't explicitly implement ConfigSpecifier, would that break > > > compatibility? These are the two cases that come to mind immediately > but > > if > > > any others occur to you feel free to document them as well. This > coverage > > > can also help guide us in how to document the interface if/when we add > it > > > to make it clear to plugin developers how to avoid rendering their work > > > accidentally incompatibile with older versions of the Connect runtime. > > > > > > 3. There's also the pluggable ConnectRestExtension > > > and ConnectorClientConfigOverridePolicy interfaces. Neither currently > > > exposes a config method but it wouldn't be out of the question to add > one > > > now to them with a default implementation that returns an empty > > ConfigDef. > > > Thoughts? > > > > > > Cheers, > > > > > > Chris > > > > > > On Wed, Jan 21, 2026 at 10:33 AM Mario Fiore Vitale via dev < > > > [email protected]> wrote: > > > > > > > Hi Everyone, > > > > > > > > I would like to start a discussion on KIP-1273: Improve Connect > > > > configurable components discoverability [1]. > > > > > > > > Summary: > > > > The idea is to introduce a common ConfigSpecifier interface for Kafka > > > > Connect components that expose configuration metadata. By unifying > the > > > > existing config() method across connectors, converters, > > transformations, > > > > and predicates under a single contract, it simplifies component > > > discovery, > > > > reduces code duplication and enables uniform tooling for > configuration > > > > introspection, validation, documentation, and UI generation. The > change > > > is > > > > fully backward compatible and requires no modifications to existing > > > > component implementations. > > > > > > > > [1] > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1273%3A+Improve+Connect+configurable+components+discoverability > > > > > > > > Regards, > > > > Mario > > > > > > > > > >
