+1 for ismael's suggestion. grouping of methods by the relevant resource will simply the API. In future, we will be adding delegation token related operations to admin client. I can imagine methods like adminClient.token().create(...), adminClient.token().renew(...), etc..
Thanks, Manikumar On Sun, Feb 5, 2017 at 7:27 PM, Ismael Juma <ism...@juma.me.uk> wrote: > 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 >
