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