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
