kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ismael Juma <ism...@juma.me.uk>
Subject Re: [DISCUSS] KIP-117: Add a public AdministrativeClient API for Kafka admin operations
Date Sun, 05 Feb 2017 13:57:43 GMT
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 <cmccabe@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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message