Hey Colin, This is great, thought I'd throw out a couple of opinions to the mix, feel free to ignore:
- I think it would be good to not use "get" as the prefix for things making remote calls. We've tried to avoid the java getter convention entirely (see code style guide), but for remote calls in particular it kind of blurs the line between field access and remote RPC in a way that leads people to trouble. What about, e.g., fetchAllGroups() vs getAllGroups(). - I think futures and callbacks are a bit of a pain to use. I'd second Becket's comment: let's ensure there a common use case motivating these that wouldn't be just as easily satisfied with batch operations (which we seem to have at least for some things). In terms of flexibility Callbacks > Futures > Batch Ops but I think in terms of usability it is the exact opposite so let's make sure we have worked out how the API will be used before deciding. In particular I think java Futures are often an uncomfortable half-way point since calling get() and blocking the thread is often not what you want for chaining sequences of operations in a truly async way, so 99% of people just use the future as a way to batch calls. - Personally I don't think splitting the admin methods up actually makes things more usable. It just makes you have to dig through our hierarchy. I think a flat class with a bunch of operations (like the consumer api) is probably the easiest for people to grok and find things on. I am kind of a dumb PHP programmer at heart, though. -Jay On Tue, Feb 7, 2017 at 10:19 AM, Colin McCabe <cmcc...@apache.org> wrote: > On Tue, Feb 7, 2017, at 08:37, Ismael Juma wrote: > > Hi all, > > > > I think it's good that we have discussed a number of API that would make > > sense in the AdminClient. Having done that, I think we should now narrow > > the focus of this KIP to a small set of methods to get us started. Once > > we > > have an AdminClient in the codebase, we can propose subsequent KIPs to > > enrich it. I would suggest the following: > > > > 1. Let's focus on topic management operations: describe, create, alter > > and > > delete topics. > > 2. Let's add an @Unstable annotation to the class and specify in the > > javadoc that the methods are subject to change (if necessary). > > > > Thoughts? > > +1. > > I'm going to reorganize the proposal a bit to use futures and to have > the grouping by API type proposed earlier. > > best, > Colin > > > > > Ismael > > > > On Fri, Feb 3, 2017 at 6:24 PM, Colin McCabe <cmcc...@apache.org> wrote: > > > > > On Thu, Feb 2, 2017, at 21:45, Becket Qin wrote: > > > > Hi Colin, > > > > > > > > Thanks for the KIP. An admin client is probably a must after we block > > > > direct access to ZK. Some comments and thoughts below: > > > > > > > > 1. Do we have a clear scope for the admin client? It might be worth > > > > thinking about the entire user experience of the admin client. > Ideally we > > > > may want to have a single client to do all the administrative work > > > > instead > > > > of having multiple ways to do different things. For example, do we > want > > > > to > > > > add topic configurations change API in the admin client? What about > > > > partition movements and preferred leader election? Those are also > > > > administrative tasks which seem reasonable to be integrated into the > > > > admin > > > > client. > > > > > > Thanks for the comments, Becket! > > > > > > I agree that topic configuration change should be in the administrative > > > client. I have not thought about partition movement or preferred > leader > > > election. It probably makes sense to put them in the client as well, > > > but we should probably have a longer discussion about those features > > > later when someone is ready to implement them ;) > > > > > > best, > > > Colin >
