From dev-return-103472-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Mon Apr 22 18:09:49 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6E64E18064D for ; Mon, 22 Apr 2019 20:09:49 +0200 (CEST) Received: (qmail 78803 invoked by uid 500); 22 Apr 2019 18:09:42 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 78791 invoked by uid 99); 22 Apr 2019 18:09:41 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Apr 2019 18:09:41 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 1100AC5CAA for ; Mon, 22 Apr 2019 18:09:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.802 X-Spam-Level: * X-Spam-Status: No, score=1.802 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 1lYSPTAQhCGZ for ; Mon, 22 Apr 2019 18:09:38 +0000 (UTC) Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 716705F353 for ; Mon, 22 Apr 2019 18:09:37 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id t21so6083473pfh.2 for ; Mon, 22 Apr 2019 11:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=K4aQp4jqdXTBMKjWRswwXnECRdYnZs7dYSXpekXUSus=; b=OXCtiUyaVOEFHgerSreWrDN7kWTmrmqesT9AGuHKLg+bMf9ryPT6uFhKOtvETf/2Ub W5V6mqyE2KKzYcu1uI5WBfv+sE1Iv1O6c48ho5x+ZGwCsXj8dq2XqEAmNwp4EghMY6y/ sP3k/0jBv1/svFxwtOxYlGV7sCO6rWSmBNQ3e43F5O3srT3LEr20lZsCd7E6ymeGQo5P 7MHgYY6Ja4FVaFxUWZGwf4as5sUC6emW5H+fY3jOSeC6j7QKxEK4brzrXBQAtf2EMGbD J9LI36kz20bQJDANdoa3WK6+E99sdkVBvUJvVR0F9SaUnvWHhZ5GZn9D9Xcit111LPB1 8riQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=K4aQp4jqdXTBMKjWRswwXnECRdYnZs7dYSXpekXUSus=; b=QCRCS9Is4i/8Zpw/gCu1KLwJEeCxi3iQsQm76wP2zAHkjmxneXZZYElgZmTfKh+bop w9qWJe7nIPET7Jx4fke30mdNr5t+2eIqHlsJs/64u/mY1E9OKYYBKeI17xoLK0wKiB6h P++LBOc/Rb/cEpH+kIx6PJgtIK87JQY7emMFll+0TLmn5idI3MrzEXRcJ5i3mKNFQGdp HBv/z1NUp3ZRByJrcrChvZys0STkhj7X2MR+M8uaVcC9m0qxREe96Psr5gIaMuurP97J OkHt8Vg4LPHFaaqrwzpRQm6f4ybDASxTON1Q+CGXYrmXx1q+fhZhHZMng0j+KMvqmqH8 L8qA== X-Gm-Message-State: APjAAAVyDOnEtqyDgA5cg+7KzLTX73uLCnjY6v7ChIsdVXyNDOYVQyh3 IBsPQhy7llZDTqm8JbOts5OdSXNNwzwffXkFcPjiRvIt X-Google-Smtp-Source: APXvYqxfUAgmquBMZ056QAXNyvdC60Ky7LodeipcY0JvRS+RnwfvgZIU/u7egjPeCVN+Fxe5R75CR4JL/KS1teLDZhE= X-Received: by 2002:a62:aa01:: with SMTP id e1mr22127200pff.43.1555956575855; Mon, 22 Apr 2019 11:09:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Randall Hauch Date: Mon, 22 Apr 2019 13:09:24 -0500 Message-ID: Subject: Re: [DISCUSS] KIP-440: Extend Connect Converter to support headers To: dev Content-Type: multipart/alternative; boundary="000000000000fd68c30587225e71" --000000000000fd68c30587225e71 Content-Type: text/plain; charset="UTF-8" Konstantine raises a good point. Which `Headers` is being referenced in the API? The Connect `org.apache.kafka.connect.header.Headers` would correspond to what was already deserialized by the `HeaderConverter` or what will yet be serialized by the `HeaderConverter`. Alternatively, the common ` org.apache.kafka.common.header.Headers` would correspond to the raw header pairs from the underlying Kafka record. So, we probably want to be a bit more specific, and also mention why. And we probably want to mention the other approach in the rejected alternatives. Best regards, Randall On Mon, Apr 22, 2019 at 11:59 AM Konstantine Karantasis < konstantine@confluent.io> wrote: > Thanks for the KIP Yaroslav! > > Apologies for the late comment. However, after reading the KIP it's still > not very clear to me what happens to the existing > HeaderConverter interface and what's the expectation for existing code > implementing this interface out there. > > Looking at the PR I see that the existing code is leaving the existing > connect headers conversion unaffected. I'd expect by reading the KIP to > understand what's the interplay of the current proposal with the existing > implementation of KIP-145 that introduced headers in Connect. > > Thanks, > Konstantine > > On Mon, Apr 22, 2019 at 9:07 AM Randall Hauch wrote: > > > Thanks for updating the KIP. It looks good to me, and since there haven't > > been any other issue mentioned in this month-long thread, it's probably > > fine to start a vote. > > > > Best regards, > > > > Randall > > > > On Tue, Apr 2, 2019 at 3:12 PM Randall Hauch wrote: > > > > > Thanks for the submission, Yaroslav -- and for building on the > suggestion > > > of Jeremy C in https://issues.apache.org/jira/browse/KAFKA-7273. This > is > > > a nice and simple approach that is backward compatible. > > > > > > The KIP looks good so far, but I do have two specific suggestions to > make > > > things just a bit more explicit. First, both the "Public API" and > > "Proposed > > > Changes" sections could be more explicit that the methods in the > proposal > > > are being added; as it's currently written a reader must infer that. > > > Second, the "Proposed Changes" section needs to more clearly specify > that > > > the WorkerSourceTask will now use the new fromConnectData method with > the > > > headers instead of the existing method, and that the WorkerSinkTask > will > > > now use the toConnectData method with the headers instead of the > existing > > > method. > > > > > > Best regards, > > > > > > Randall > > > > > > > > > On Mon, Mar 11, 2019 at 11:01 PM Yaroslav Tkachenko < > sapiensy@gmail.com> > > > wrote: > > > > > >> Hello, > > >> > > >> I'd like to propose a KIP that extends Kafka Connect Converter > > interface: > > >> > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-440%3A+Extend+Connect+Converter+to+support+headers > > >> > > >> Thanks for considering! > > >> > > >> -- > > >> Yaroslav Tkachenko > > >> sap1ens.com > > >> > > > > > > --000000000000fd68c30587225e71--