Hi Jay, On Wed, Apr 6, 2016 at 3:48 AM, Jay Kreps <j...@confluent.io> wrote:
> Given that we're breaking compatibility anyway should we: > We are not breaking source compatibility since the new method has a default implementation. I take it that you mean binary compatibility? > 1. Remove the get prefix on this method and the existing one which violate > our own code style guidelines (Oops! Kind of sad we went through the whole > KIP process and no one even flagged this) > I did flag this during the discussion and Ashish said he would change it if other people felt that it should be changed. > 2. Move the interface out of scala to be a normal Java interface > > This breaks source compatibility but probably what we should have done > originally I suspect. Probably there are few enough implementations of this > that it is better to just rip the bandaid off. > Can you please explain the motivation? It did come up in previous discussions that some things like Operation and ResourceType should be in the clients library, but not Authorizer itself. Are we saying that any pluggable interface should be in Java so that users can implement it without including the Scala library? Grant, you originally suggested that some things would have to be in the Java side as well. Can you please elaborate on this? Ismael
