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 >
