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 > > >
