Agree. Regardless of which one of us understood the KIP correctly, this
kind of thing should be crystal clear in the KIP.
On Mon, Mar 14, 2016 at 2:12 PM, Ismael Juma <ism...@juma.me.uk> wrote:
> On Mon, Mar 14, 2016 at 8:45 PM, Gwen Shapira <g...@confluent.io> wrote:
> >
> > > I don't see how it helps. If the client is communicating with a broker
> > that
> > > does not support KIP-35, that broker will simply close the connection.
> If
> > > the broker supports KIP-35, then it will provide the broker version. I
> > > don't envisage a scenario where a broker does not support KIP-35, but
> > > implements the new behaviour of sending an empty response. Do you?
> > >
> > > Are you sure about that? Per KIP-35, the broker supplies the version in
> > response to Metadata request, not in response to anything else.
> > If the client sends producer request version 42 (accidentally or due to
> > premature upgrade) to KIP-35-compactible broker - we want to see an empty
> > packet and not a connection close.
> > Sending a broker version was deemed impractical IIRC.
> >
>
> OK, so this is a different case than the one Ashish described ("client that
> wants to support broker versions that do not provide broker version in
> metadata and broker versions that provides version info in metadata"). So,
> you are suggesting that if a client is communicating with a broker that
> implements KIP-35 and it receives an empty response, it will assume that
> the broker doesn't support the request version and it won't try to parse
> the response? I think it would be good to explain this kind of thing in
> detail in the KIP.
>
> Ismael
>
