The concern is maintaining a potentially unbounded list of add-ons as part of Kafka.
I think the pros/cons were well discussed, I am happy we added a provision specifically excluding transformations that depend on specific data sources, and I'd much rather get SMT than continuing to debate how many transformations could possibly exist. On Wed, Jan 4, 2017 at 2:27 PM, Ewen Cheslack-Postava <e...@confluent.io> wrote: > +1 > > Gwen, re: bundling transformations, would it help at all to isolate them to > a separate jar or is the concern purely about maintaining them as part of > Kafka? > > -Ewen > > On Wed, Jan 4, 2017 at 1:31 PM, Sriram Subramanian <r...@confluent.io> wrote: > >> +1 >> >> On Wed, Jan 4, 2017 at 1:29 PM, Gwen Shapira <g...@confluent.io> wrote: >> >> > I would have preferred not to bundle transformations, but since SMT >> > capability is a much needed feature, I'll take it in its current form. >> > >> > +1 >> > >> > On Wed, Jan 4, 2017 at 10:47 AM, Shikhar Bhushan <shik...@confluent.io> >> > wrote: >> > > Hi all, >> > > >> > > I'd like to start voting on KIP-66: >> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> > 66%3A+Single+Message+Transforms+for+Kafka+Connect >> > > >> > > Best, >> > > >> > > Shikhar >> > >> > >> > >> > -- >> > Gwen Shapira >> > Product Manager | Confluent >> > 650.450.2760 | @gwenshap >> > Follow us: Twitter | blog >> > >> -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
