Ismael,

Thank you, will make it clear in the docs that mechanism can be passed even
for GSSAPI from 0.10.0.0.

On Tue, Mar 1, 2016 at 2:59 PM, Ismael Juma <ism...@juma.me.uk> wrote:

> Hi Rajini,
>
> Thanks for clarifying. Comments inline.
>
> On Tue, Mar 1, 2016 at 2:21 PM, Rajini Sivaram <
> rajinisiva...@googlemail.com
> > wrote:
> >
> > Since we want to support arbitrary custom mechanisms, it feels better to
> > use mechanism names rather than Strings. IDs would require ensuring that
> > client and server have the same mapping. Since the mechanism name Strings
> > are not particularly long and they are useful for debugging, I feel it is
> > worthwhile to retain Strings rather than IDs.
> >
>
> Fair enough.
>
> I wasn't sure whether Kafka attempted to retain compatibility in both
> > directions. I would have preferred to send the mechanism even for GSSAPI
> to
> > keep the code consistent, but went for version compatibility instead. I
> was
> > thinking mainly of replication. If you have a cluster that uses 0.9.0.x
> > with SASL replication, it would be easier to upgrade if new clients
> worked
> > with old brokers.
> >
>
> That makes sense. We could use inter.broker.protocol.version for the
> replication case, but `SaslClientAuthenticator` is shared between clients
> and the broker and the way you did is probably simpler. However, the other
> side of the coin is how we document the protocol for clients that are
> distributed separately from Kafka itself. It would be good to make it clear
> in such documentation that one can pass the mechanism even for the GSSAPI
> case from 0.10.0.0 onwards.
>
> Ismael
>



-- 
Regards,

Rajini

Reply via email to