Hi Chris and Mickael, So, in this case, I like the second option, which is also more aligned with my proposal to use "ConnectPlugin" as the name. In the end, we will have the "ConnectPlugin" used for both connector and worker plugins.
I'll do the changes on the KIP. Do you think we are ready for a vote then? Thanks, Mario. Il giorno ven 13 feb 2026 alle ore 16:18 Mickael Maison < [email protected]> ha scritto: > Hi, > > I agree on the "pick one of these two mutually-exclusive options" point. > I'm fine with either option. > > Thanks, > Mickael > > On Thu, Feb 12, 2026 at 8:29 PM Chris Egerton <[email protected]> > wrote: > > > > Hi Mario, > > > > I think the idea with "ConnectorPlugin" is that it only applies to > plugins > > that are used directly by connectors, which excludes worker-level plugins > > like the connector client override policy and REST extension interfaces. > So > > IMO we should pick one of these two mutually-exclusive options: > > > > 1. Name the parent interface "ConnectorPlugin" and only use it for > > connector plugins but not worker plugins* > > 2. Name the parent interface something else (maybe just "ConnectPlugin"?) > > and use it for both connector and worker plugins > > > > * - Note that this doesn't preclude us from adding a config() method to > the > > worker plugin interfaces, just from using the same parent interface name > as > > the one for connector plugins > > > > I'd lean towards the second option but I'd accept either. I suspect > Mickael > > would prefer the first but will let him weigh in :) > > > > Cheers, > > > > Chris > > > > On Fri, Feb 6, 2026 at 5:54 AM Mario Fiore Vitale via dev < > > [email protected]> wrote: > > > > > Hi Everyone, > > > > > > I have updated the KIP document with the ConnectorPlugin. I'll > appreciate > > > any feedback. > > > > > > Thanks, > > > Mario. > > > > > > Il giorno ven 6 feb 2026 alle ore 09:37 Mario Fiore Vitale < > > > [email protected]> ha scritto: > > > > > > > Hi Mickael, > > > > > > > > I got it. So I'll update the KIP with the ConnectorPlugin interface > > > having > > > > version() and config() methods. > > > > > > > > Thanks, > > > > Mario > > > > > > > > Il giorno gio 5 feb 2026 alle ore 18:24 Mickael Maison < > > > > [email protected]> ha scritto: > > > > > > > >> Hi, > > > >> > > > >> Connectors, transformations, predicates are typically referred as > > > >> "connector plugins". > > > >> On the other hand ConnectRestExtension, > > > >> ConnectorClientConfigOverridePolicy and ConfigProvider are "worker > > > >> plugins". > > > >> Yes it's confusing! The terms connectors and plugins are really > > > overused. > > > >> > > > >> Mickael > > > >> > > > >> On Thu, Feb 5, 2026 at 5:58 PM Mario Fiore Vitale via dev > > > >> <[email protected]> wrote: > > > >> > > > > >> > > 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? > > > >> > > > > >> > So If I get it correctly, you are proposing to have a single > interface > > > >> > (ConnectorPlugin) that replaces the Versioned and the > > > >> > ConfigSpecifier, merging them. > > > >> > Sounds reasonable. In that case, I'll use a more generic name like > > > >> > *ConnectPlugin > > > >> > *since it will be used not only for connectors but also for > > > >> transformation, > > > >> > predicates, and converters. > > > >> > > > > >> > Mickael, Chris, WDYT? > > > >> > > > > >> > > I like the ConnectorPlugin interface idea. Mario, would that > suit > > > >> your use > > > >> > case? > > > >> > > > > >> > The result is the same, so it is good. > > > >> > > > > >> > Thanks, > > > >> > Mario. > > > >> > > > > >> > Il giorno gio 5 feb 2026 alle ore 16:53 Chris Egerton < > > > >> > [email protected]> ha scritto: > > > >> > > > > >> > > 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 > > > >> > > > > >> > > > > > > >> > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > >
