Thanks for the feedback, Chris. WRT Worker-plugins, I see your point that they aren't very useful for people trying to create connectors to see what exists already, but I would find them useful for things like making assertions against a docker image to confirm the pluginpaths/classpaths are configured correctly. It is more useful for "sanity check" kinds of things than exploring/browsing. That said, I don't feel too strongly and if more feedback from the community thinks they are better excluded then we can remove them.
WRT camelCase vs hyphens, I see your point here, will update the KIP. WRT compatibility -- Good question -- I would expect that yes, new plugins would match this format. I will add this explicitly in the KIP for clarity. I do think it's a valuable, simple feature to have the worker able to report new plugins. Thanks again! On Wed, Feb 12, 2020 at 4:44 PM Christopher Egerton <chr...@confluent.io> wrote: > Hi Cyrus, > > Thanks for the KIP! > > One quick question--I see the use case for being able to list per-connector > plugins (SMTs, converters, and header converters) via REST API, but I'm not > so sure about worker plugins (REST extensions and config providers). Since > those are configured at startup for the worker, is there any advantage to > being able to see the worker plugins available on a running worker? It's > not like they can be added during the lifetime of that worker, and that > information wouldn't be useful to anyone trying to create a connector as > they wouldn't be able to include worker plugins in a connector config > anyways. > > And a small nit--it seems like the precedent set ever-so-slightly by the > /connector-plugins resource is to use a hyphen to separate a series of > lowercase words in an endpoint path as opposed to camel case with > capitalization. What do you think about changing the possible plugin types > to "connector", "converter", "header-converter", etc.? > > One final question about forwards compatibility--the description for the > /plugins endpoint indicates that it "Returns plugin descriptions of all > types". If another type of pluggable component is added to the framework, > should we expect this endpoint to be updated to include that type of plugin > as well? And if so, should we also expect a matching /plugins/{pluginType} > endpoint to be added? > > Cheers, > > Chris > > On Fri, Sep 6, 2019 at 11:48 AM Cyrus Vafadari <cy...@confluent.io> wrote: > > > I've updated the KIP here to simplify and clarify the goal -- it's a > pretty > > simple KIP to add a REST endpoint for SMTs and other plugins. This will > > make it easier to see what SMTs you've loaded. > > > > Hoping for some good discussion! > > > > Thanks, all > > > > On Sat, Jul 20, 2019 at 9:07 PM Cyrus Vafadari <cy...@confluent.io> > wrote: > > > > > Hello, all, > > > > > > I'd like to start discussion on a new KIP I'm proposing to add HTTP > > > endpoints to Kafka Connect to give us some more insight into other > > > non-connector plugins, like Simple Message Transformations (SMTs). The > > KIP > > > would not change how Connect works in any meaningful way except to > expose > > > some more data by the endpoint, analogous to existing > > > "ConnectorPluginsResource" class. > > > > > > Looking forward to getting some feedback. > > > > > > Cyrus > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-494%3A+Connect+REST+Endpoint+for+Transformations+%28SMTs%29+and+other+Plugins > > > > > >