Hi Colin, I was thinking about the API and the fact that the AdminClient will be used by a variety of somewhat unrelated things (unlike the Consumer and Producer), so I think we should consider an approach where not all the methods are at the top-level. One idea is that you could perform operations on topics by doing something like `adminClient.topics().create(...)`, `adminClient.topics().delete(...)`, `adminClient.topics().describe(...)`, etc. This is just an initial sketch to describe the idea, but I think it would be a nice way to group methods by the relevant resource. It would also make it easier to enforce consistency by using shared interfaces for the types returned by the resource method (e.g. `topics()`, `acls()`, etc.).
One additional comment inline. On Fri, Feb 3, 2017 at 6:40 PM, Colin McCabe <cmcc...@apache.org> wrote: > > I guess my thought process was that users might find it confusing if the > public API and the old private API had the same name. "What do you > mean, I have to upgrade to release X to get AdminClient, I have it right > here?" I do have a slight preference for the shorter name, though, so > if this isn't a worry, we can change it to AdminClient. > Yes, I don't think this is a worry. The package name and implementation language are different, so it's easy enough to distinguish. We should not choose a worse name for a public class because of an internal class, as a general rule, in my opinion. More to follow later. Ismael
