I agree that ConfigSpecifier is a little clunky, but IMO Configured is a little too be similar to the existing Configurable interface.
I like the ConnectorPlugin interface idea. Mario, would that suit your use case? On Thu, Feb 5, 2026, 10:24 Mickael Maison <[email protected]> wrote: > Hi Mario, > > Thanks for the KIP. > > Today the mechanism to discover plugins and their configurations is > the REST API. > You can retrieve the list of all installed connectors plugins > (connectors, transformations, predicates) via GET > /connector-plugins?connectorsOnly=false > You can get their configurations via GET /connector-plugins/{plugin}/config > > That said, I'm not against bringing consistency to the plugin APIs, > especially as the drawbacks are really minor. > In terms of naming I'm not a huge fan of ConfigSpecifier. I don't have > a great alternative to suggest. > To follow the naming of Versioned, maybe we can consider Configured? > Otherwise we could have a ConnectorPlugin interface (putting aside the > worker plugins for now as they don't have a config() method) bringing > config() and version() that all plugins interface would implement? > > Thanks, > Mickael > > > On Mon, Feb 2, 2026 at 9:48 AM Mario Fiore Vitale via dev > <[email protected]> wrote: > > > > Hi Everyone, > > > > Just a ping to bring the discussion up. > > > > Thanks, > > Mario. > > > > Il giorno mar 27 gen 2026 alle ore 09:17 Mario Fiore Vitale < > > [email protected]> ha scritto: > > > > > 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 > > >> > > > > > >> > > > > >> > > > >> > > > >
