So my only 2 cents on this KIP is mainly from a REST perspective, i.e. in the KIP you mention that you need to add a new field "state.v2": “STOPPED” due to maintaining backwards compatibility with older brokers. My main qualm here is that putting versioning into JSON field names isn’t typically the best from a REST design perspective. I would propose using something like “current_state": “STOPPED” instead or anything other field name that seems appropriate.
There may be other alternatives as well but in summary there appears to be a tradeoff between making sure the new design is clean from a REST standpoint (which is where I am personally leaning) versus making the transition easier/more understandable for older brokers. Regards, -- Matthew de Detrich Aiven Deutschland GmbH Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen m: +491603708037 w: aiven.io e: matthew.dedetr...@aiven.io On 13. Oct 2022, 22:52 +0200, Chris Egerton <chr...@aiven.io.invalid>, wrote: > Hi all, > > I noticed a fairly large gap in the first version of this KIP that I > published last Friday, which has to do with accommodating connectors > that target different Kafka clusters than the one that the Kafka Connect > cluster uses for its internal topics and source connectors with dedicated > offsets topics. I've since updated the KIP to address this gap, which has > substantially altered the design. Wanted to give a heads-up to anyone > that's already started reviewing. > > Cheers, > > Chris > > On Fri, Oct 7, 2022 at 1:29 PM Chris Egerton <chr...@aiven.io> wrote: > > > Hi all, > > > > I'd like to begin discussion on a KIP to add offsets support to the Kafka > > Connect REST API: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-875%3A+First-class+offsets+support+in+Kafka+Connect > > > > Cheers, > > > > Chris > >
