Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-213 Support non-key joining in KTable
To: dev@kafka.apache.org
References: <59F2B839.3080007@trivago.com> <5A0D60ED.1010501@trivago.com>
 <CAP6fLVcXd0AOoKgFycHa3_Dg9U4DTkVSc8SBQTFdFdEbBc=cMw@mail.gmail.com>
 <5A0DB7AB.3010404@trivago.com>
 <CAP6fLVcEr1b_fPbMeJ_WO9JZvCnEiG+xc8tO5MDeQFNX9JdCwg@mail.gmail.com>
 <5A0DC53C.9070501@trivago.com>
 <cc086f36-e68d-bc9c-c63f-564cfb08aa65@confluent.io>
 <5A10B471.3050707@trivago.com>
 <CAHwHRrVsLUgeDvAzdZHSgRKVhT=0YewkVEFJyw9QF6g6ukG70w@mail.gmail.com>
 <9832679d-71e6-7779-0e03-cd78e35ffd34@confluent.io>
 <5A1A4970.504@trivago.com>
From: "Matthias J. Sax" <matthias@confluent.io>
Organization: Confluent Inc
Message-ID: <e250f714-94c5-15bf-6f45-3c494a0ce329@confluent.io>
Date: Mon, 4 Dec 2017 15:42:03 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5A1A4970.504@trivago.com>
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="GHRajM5tVRrjNnFFUokpEmDXl5qcGv67H"
archived-at: Mon, 04 Dec 2017 23:42:14 -0000

--GHRajM5tVRrjNnFFUokpEmDXl5qcGv67H
Content-Type: multipart/mixed; boundary="PWJOIUu5Q9oBVXsGhFoIhPPirQ8daKEq4";
 protected-headers="v1"
From: "Matthias J. Sax" <matthias@confluent.io>
To: dev@kafka.apache.org
Message-ID: <e250f714-94c5-15bf-6f45-3c494a0ce329@confluent.io>
Subject: Re: [DISCUSS] KIP-213 Support non-key joining in KTable
References: <59F2B839.3080007@trivago.com> <5A0D60ED.1010501@trivago.com>
 <CAP6fLVcXd0AOoKgFycHa3_Dg9U4DTkVSc8SBQTFdFdEbBc=cMw@mail.gmail.com>
 <5A0DB7AB.3010404@trivago.com>
 <CAP6fLVcEr1b_fPbMeJ_WO9JZvCnEiG+xc8tO5MDeQFNX9JdCwg@mail.gmail.com>
 <5A0DC53C.9070501@trivago.com>
 <cc086f36-e68d-bc9c-c63f-564cfb08aa65@confluent.io>
 <5A10B471.3050707@trivago.com>
 <CAHwHRrVsLUgeDvAzdZHSgRKVhT=0YewkVEFJyw9QF6g6ukG70w@mail.gmail.com>
 <9832679d-71e6-7779-0e03-cd78e35ffd34@confluent.io>
 <5A1A4970.504@trivago.com>
In-Reply-To: <5A1A4970.504@trivago.com>

--PWJOIUu5Q9oBVXsGhFoIhPPirQ8daKEq4
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Jan,

The KTableValueGetter thing is a valid point. I think we would need a
backwards mapper (or merge both into one and sacrifices lambdas?).
Another alternative would be, to drop the optimization and materialize
the KTable.operator() result... (not a great solution either). I am
personally fine with a backwards mapper (we should call it KeySplitter).

>> 2. I am not sure if we can pull it of w/o said forth generic type in
>> KTable (that I am in favour of btw)

Not sure if I can follow here. I am personally not worried about the
number of generic types -- it's just to have a clear definition what
each passed parameter does.

> + It won't solves peoples problem having CombinedKey on the wire and no=
t being able to inspect the topic with say there default tools.=20

I see your point, but do we not have this issue always? To make range
scan work, we need to serialize the prefix (K1) and suffix (K)
independently from each other. IMHO, it would be too much of a burden to
the user, to provide a single serialized for K0 that guaranteed the
ordering we need. Still, advanced user can provide custom Serde for the
changelog topic via `Joined` -- and they can serialize as they wish (ie,
get CombinedKey<K1,K>, convert internally to K0 and serialized -- but
this is an opt-in).

I think, this actually aligns with what you are saying. However, I think
the #prefix() call is not the best idea. We can just use Serde<K1> for
this (if users overwrite CombinedKey-Serde, it must overwrite Serde<K1>
too and can return the proper perfix (or do I miss something?).

>  - Id rather introduce KTable::mapKeys() or something (4th generic in K=
table?) than overloading. It is better SOCs wise.=20

What overload are you talking about? From my understanding, we want to
add one single method (or maybe one for inner,left,outter each), but I
don't see any overloads atm?

Also, `KTable.mapKeys()` would have the issue, that one could create an
invalid KTable with key collisions. I would rather shield users to shoot
themselves in the foot.


Side remark:

In the KIP, in the Step-by-Step table (that I really like a lot!) I
think in line 5 (input A, with key A2 arrives, the columns "state B
materialized" and "state B other task" should not be empty but the same
as in line 4?


-Matthias


On 11/25/17 8:56 PM, Jan Filipiak wrote:
> Hi Matthias,
>=20
> 2 things that pop into my mind sunday morning. Can we provide an
> KTableValueGetter when key in the store is different from the key
> forwarded?
> 1. we would need a backwards mapper
> 2. I am not sure if we can pull it of w/o said forth generic type in
> KTable (that I am in favour of btw)
>=20
> + It won't solves peoples problem having CombinedKey on the wire and no=
t
> beeing able to inspect the topic with say there default tools.
> =C2=A0- Id rather introduce KTable::mapKeys() or something (4th generic=
 in
> Ktable?) than overloading. It is better SOCs wise.
>=20
> I am thinking more into an overload where we replace the Comined key
> Serde. So people can use a default CombinedKey Serde
> but could provide an own implementation that would internally use K0 vo=
r
> serialisation and deserialisation. One could implement
> a ##prefix() into this call to make explicit that we only want the
> prefix rendered. This would take CombinedKey logic out of publicly visi=
ble
> data. A Stock CombinedKey Serde that would be used by default could als=
o
> handle the JSON users correctly.
>=20
> Users would still get CombinedKey back. The downside of getting these
> nested deeply is probably mitgated by users doing a group by
> in the very next step to get rid of A's key again.
>=20
> That is what I was able to come up with so far.
> Let me know. what you think
>=20
>=20
>=20
>=20
> On 22.11.2017 00:14, Matthias J. Sax wrote:
>> Jan,
>>
>> Thanks for explaining the Serde issue! This makes a lot of sense.
>>
>> I discussed with Guozhang about this issue and came up with the
>> following idea that bridges both APIs:
>>
>> We still introduce CombinedKey as a public interface and exploit it to=

>> manage the key in the store and the changelog topic. For this case we
>> can construct a suitable Serde internally based on the Serdes of both
>> keys that are combined.
>>
>> However, the type of the result table is user defined and can be
>> anything. To bridge between the CombinedKey and the user defined resul=
t
>> type, users need to hand in a `ValueMapper<CombinedKey, KO>` that
>> convert the CombinedKey into the desired result type.
>>
>> Thus, the method signature would be something like
>>
>>> <KO, VO, K1, V1> KTable<KO,VO> oneToManyJoin(>=C2=A0=C2=A0=C2=A0=C2=A0=
 KTable<K1, V1> other,
>>> =C2=A0=C2=A0=C2=A0=C2=A0 ValueMapper<V1, K> keyExtractor,>=C2=A0=C2=A0=
=C2=A0=C2=A0 ValueJoiner<V, V1, VO>
>>> joiner,
>>> =C2=A0=C2=A0=C2=A0=C2=A0 ValueMapper<CombinedKey<K,K1>, KO> resultKey=
Mapper);
>> The interface parameters are still easy to understand and don't leak
>> implementation details IMHO.
>>
>> WDYT about this idea?
>>
>>
>> -Matthias
>>
>>
>> On 11/19/17 11:28 AM, Guozhang Wang wrote:
>>> Hello Jan,
>>>
>>> I think I get your point about the cumbersome that CombinedKey would
>>> introduce for serialization and tooling based on serdes. What I'm sti=
ll
>>> wondering is the underlying of joinPrefixFakers mapper: from your lat=
est
>>> comment it seems this mapper will be a one-time mapper: we use this
>>> to map
>>> the original resulted KTable<combined<K1, K2>, V0> to KTable<K0, V0> =
and
>>> then that mapper can be thrown away and be forgotten. Is that true? M=
y
>>> original thought is that you propose to carry this mapper all the way=

>>> along
>>> the rest of the topology to "abstract" the underlying combined keys.
>>>
>>> If it is the other way (i.e. the former approach), then the diagram o=
f
>>> these two approaches would be different: for the less intrusive
>>> approach we
>>> would add one more step in this diagram to always do a mapping after =
the
>>> "task perform join" block.
>>>
>>> Also another minor comment on the internal topic: I think many
>>> readers may
>>> not get the schema of this topic, so it is better to indicate that wh=
at
>>> would be the key of this internal topic used for compaction, and what=

>>> would
>>> be used as the partition-key.
>>>
>>> Guozhang
>>>
>>>
>>> On Sat, Nov 18, 2017 at 2:30 PM, Jan Filipiak <Jan.Filipiak@trivago.c=
om>
>>> wrote:
>>>
>>>> -> it think the relationships between the different used types,
>>>> K0,K1,KO
>>>> should be explains explicitly (all information is there implicitly, =
but
>>>> one need to think hard to figure it out)
>>>>
>>>>
>>>> I'm probably blind for this. can you help me here? how would you
>>>> formulate
>>>> this?
>>>>
>>>> Thanks,
>>>>
>>>> Jan
>>>>
>>>>
>>>> On 16.11.2017 23:18, Matthias J. Sax wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am just catching up on this discussion and did re-read the KIP an=
d
>>>>> discussion thread.
>>>>>
>>>>> In contrast to you, I prefer the second approach with CombinedKey a=
s
>>>>> return type for the following reasons:
>>>>>
>>>>> =C2=A0=C2=A0 1) the oneToManyJoin() method had less parameter
>>>>> =C2=A0=C2=A0 2) those parameters are easy to understand
>>>>> =C2=A0=C2=A0 3) we hide implementation details (joinPrefixFaker,
>>>>> leftKeyExtractor,
>>>>> and the return type KO leaks internal implementation details from m=
y
>>>>> point of view)
>>>>> =C2=A0=C2=A0 4) user can get their own KO type by extending Combine=
dKey
>>>>> interface
>>>>> (this would also address the nesting issue Trevor pointed out)
>>>>>
>>>>> That's unclear to me is, why you care about JSON serdes? What is th=
e
>>>>> problem with regard to prefix? It seems I am missing something here=
=2E
>>>>>
>>>>> I also don't understand the argument about "the user can stick with=

>>>>> his
>>>>> default serde or his standard way of serializing"? If we have
>>>>> `CombinedKey` as output, the use just provide the serdes for both
>>>>> input
>>>>> combined-key types individually, and we can reuse both internally
>>>>> to do
>>>>> the rest. This seems to be a way simpler API. With the KO output ty=
pe
>>>>> approach, users need to write an entirely new serde for KO in
>>>>> contrast.
>>>>>
>>>>> Finally, @Jan, there are still some open comments you did not addre=
ss
>>>>> and the KIP wiki page needs some updates. Would be great if you
>>>>> could do
>>>>> this.
>>>>>
>>>>> Can you also explicitly describe the data layout of the store that =
is
>>>>> used to do the range scans?
>>>>>
>>>>> Additionally:
>>>>>
>>>>> -> some arrows in the algorithm diagram are missing
>>>>> -> was are those XXX in the diagram
>>>>> -> can you finish the "Step by Step" example
>>>>> -> it think the relationships between the different used types,
>>>>> K0,K1,KO
>>>>> should be explains explicitly (all information is there implicitly,=

>>>>> but
>>>>> one need to think hard to figure it out)
>>>>>
>>>>>
>>>>> Last but not least:
>>>>>
>>>>> But noone is really interested.
>>>>> Don't understand this statement...
>>>>>
>>>>>
>>>>>
>>>>> -Matthias
>>>>>
>>>>>
>>>>> On 11/16/17 9:05 AM, Jan Filipiak wrote:
>>>>>
>>>>>> We are running this perfectly fine. for us the smaller table chang=
es
>>>>>> rather infrequent say. only a few times per day. The performance
>>>>>> of the
>>>>>> flush is way lower than the computing power you need to bring to t=
he
>>>>>> table to account for all the records beeing emmited after the one
>>>>>> single
>>>>>> update.
>>>>>>
>>>>>> On 16.11.2017 18:02, Trevor Huey wrote:
>>>>>>
>>>>>>> Ah, I think I see the problem now. Thanks for the explanation.
>>>>>>> That is
>>>>>>> tricky. As you said, it seems the easiest solution would just be =
to
>>>>>>> flush the cache. I wonder how big of a performance hit that'd be.=
=2E.
>>>>>>>
>>>>>>> On Thu, Nov 16, 2017 at 9:07 AM Jan Filipiak
>>>>>>> <Jan.Filipiak@trivago.com
>>>>>>> <mailto:Jan.Filipiak@trivago.com>> wrote:
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Trevor,
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am leaning towards the less intr=
usive approach myself.
>>>>>>> Infact
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that is how we implemented our Int=
ernal API for this and
>>>>>>> how we
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 run it in production.
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 getting more voices towards this s=
olution makes me really
>>>>>>> happy.
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The reason its a problem for Prefi=
x and not for Range is the
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 following. Imagine the intrusive a=
pproach. They key of the
>>>>>>> RockDB
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 would be CombinedKey<A,B> and the =
prefix scan would take an
>>>>>>> A, and
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the range scan would take an Combi=
nedKey<A,B> still. As you
>>>>>>> can
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 see with the intrusive approach th=
e keys are actually
>>>>>>> different
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 types for different queries. With =
the less intrusive
>>>>>>> apporach we
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 use the same type and rely on Serd=
e Invariances. For us
>>>>>>> this works
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 nice (protobuf) might bite some JS=
ON users.
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hope it makes it clear
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best Jan
>>>>>>>
>>>>>>>
>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On 16.11.2017 16:39, Trevor Huey w=
rote:
>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. Going over KIP-213, I am leani=
ng toward the "less
>>>>>>>> intrusive"
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 approach. In my use case, I am pl=
anning on performing a
>>>>>>>> sequence
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of several oneToMany joins, From =
my understanding, the more
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 intrusive approach would result i=
n several nested levels of
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CombinedKey's. For example, consi=
der Tables A, B, C, D with
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 corresponding keys KA, KB, KC. Jo=
ining A and B would produce
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CombinedKey<KA, KB>. Then joining=
 that result on C would
>>>>>>>> produce
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CombinedKey<KC, CombinedKey<KA, K=
B>>. My "keyOtherSerde"
>>>>>>>> in this
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case would need to be capable of =
deserializing
>>>>>>>> CombinedKey<KA,
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 KB>. This would just get worse th=
e more tables I join. I
>>>>>>>> realize
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that it's easier to shoot yoursel=
f in the foot with the less
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 intrusive approach, but as you sa=
id, " the user can stick
>>>>>>>> with
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 his default serde or his standard=
 way of serializing". In the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 simplest case where the keys are =
just strings, they can do
>>>>>>>> simple
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string concatenation and Serdes.S=
tring(). It also allows
>>>>>>>> the user
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to create and use their own versi=
on of CombinedKey if they
>>>>>>>> feel
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so inclined.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. Why is there a problem for pre=
fix, but not for range?
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 https://github.com/apache/kafka/pull/37=
20/files#diff-8f863b7
>>>>>>>> 4c3c5a0b989e89d00c149aef1L162
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Thu, Nov 16, 2017 at 2:57 AM J=
an Filipiak
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <Jan.Filipiak@trivago.com <mailto=
:Jan.Filipiak@trivago.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Trevor=
,
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 thank you=
 very much for your interested. Too keep
>>>>>>>> discussion
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mailing l=
ist focused and not Jira or Confluence I
>>>>>>>> decided to
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reply her=
e.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. its tr=
icky activity is indeed very low. In the KIP-213
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 there are=
 2 proposals about the return type of the
>>>>>>>> join. I
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 would lik=
e to settle on one.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Unfortuna=
tly its controversal and I don't want to have
>>>>>>>> the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 discussio=
n after I settled on one way and implemented
>>>>>>>> it. But
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 noone is =
really interested.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 So discus=
sing with YOU, what your preferred return
>>>>>>>> type would
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 look woul=
d be very helpfull already.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The most =
difficult part is implementing
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>> https://github.com/apache/kafka/pull/3720/files#diff-ac41b4d
>>>>>>>> fb9fc6bb707d966477317783cR68
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 here
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>> https://github.com/apache/kafka/pull/3720/files#diff-8f863b7
>>>>>>>> 4c3c5a0b989e89d00c149aef1R244
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and here
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>> https://github.com/apache/kafka/pull/3720/files#diff-b1a1281
>>>>>>>> dce5219fd0cb5afad380d9438R207
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 One can g=
et an easy shot by just flushing the underlying
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rocks and=
 using Rocks for range scan.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 But as yo=
u can see the implementation depends on the
>>>>>>>> API. For
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wich way =
the API discussion goes
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I would i=
mplement this differently.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I only ha=
ve so and so much time to work on this. I
>>>>>>>> filed the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 KIP becau=
se I want to pull it through and I am pretty
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 confident=
 that I can do it.
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 But I am =
still waiting for the full discussion to
>>>>>>>> happen on
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this. To =
get the discussion forward it seems to be that I
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 need to f=
ill out the table in
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the KIP e=
ntirly (the one describing the events, change
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 modificat=
ions and output). Feel free to continue the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 discussio=
n w/o the table. I want
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to finish=
 the table during next week.
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Best Jan =
thank you for your interest!
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 _____ Jir=
a Quote ______
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jan Filip=
iak
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
>>>>>>>> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name
>>>>>>>> =3Djfilipiak>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please be=
ar with me while I try to get caught up. I'm
>>>>>>>> not yet
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 familiar =
with the Kafka code base. I have a few
>>>>>>>> questions to
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 try to fi=
gure out how I can get involved:
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. It see=
ms like we need to get buy-in on your
>>>>>>>> KIP-213? It
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 doesn't s=
eem like there's been much activity on it
>>>>>>>> besides
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yourself =
in a while. What's your current plan of
>>>>>>>> attack for
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 getting t=
hat approved?
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. I know=
 you said that the most difficult part is yet
>>>>>>>> to be
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 done. Is =
there some code you can point me toward so I can
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 start dig=
ging in and better understand why this is so
>>>>>>>> difficult?
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3. This i=
ssue has been open since May '16. How far out
>>>>>>>> do you
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 think we =
are from getting this implemented?
>>>>>>>>
>>>>>>>>
>>>
>=20


--PWJOIUu5Q9oBVXsGhFoIhPPirQ8daKEq4--

--GHRajM5tVRrjNnFFUokpEmDXl5qcGv67H
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQJKBAEBCgA0FiEEFpAnjJ4fbvgzKNUmjQjbao0qTDYFAlol3UsWHG1hdHRoaWFz
QGNvbmZsdWVudC5pbwAKCRCNCNtqjSpMNmXmD/9ymVVqHVHesvI+c2kn0dnimdlm
zelPpP5ArCWkrcRkm57xc6A0B1FwVsncNc4shqoR2u6X9lPF5SkPfBMOxk8RsPSw
PVmUB/k8coMl1JxfbiCGFjn1dSRO4FIbIsSKh7X6N8IQ4tqrjCn12U3cGEWhT2+k
fBTlWkdAyPhDpa4szdYVGiumHxiOyCDyPTyWB//c+s1SDFhOwiWHwImb+Bcg9OsO
7zl0x6uY/CPNw9WcdU3paANfOKUeX06sUIo1ZranKu73y7QBErd71ni+PGQTN3jE
QakUDMQTI4nRh//c9s/PDFj4jln+uJGDITqfHw4t+daOB3OXhDwm3RAzXNM2eSfz
0WJsSd9hohmC84MKnkhERhy8m3UxeNaWLTqzVhwdCY6UK7jdrQyr+8JyrRCQrxoL
R36LWjt8oQ2efUFb9BSLAO0LH7Ym5ovKEQQ5GyV0VGPS9QxkJInrnnXxgInNwMdJ
RJI2MAuOzlg1IKgRr5tQRZ19ePQ/lMs+wYM0L0pRhuYPl+lNXSCcaLwxDIUUWBHa
NuuzC65bzNEGZ0O1tWOU8qYGsv5Y3Da/IO0IgleWO27CGMnkplq7ZE+TWh+f2C9L
Mp3bMf8E1aHnf25zlSDjr5iw2DjUPGTyfbGXMlA9jkEeuicsY3DnMoFndfd4kFL4
WcF4WeJ5o6lNKYAKog==
=HvKb
-----END PGP SIGNATURE-----

--GHRajM5tVRrjNnFFUokpEmDXl5qcGv67H--