>
> Yes, I think empty should be "no topics" too. However, I would suggest
> using a boolean to indicate "all topics" and null should not be allowed (as
> it is now). I think this is a clearer API and it's similar to
> how org.apache.kafka.clients.Metadata works today.


+1. Having null imply all is almost as weird as using empty, though at
least it avoids the most common usage problem.

-Jason

On Wed, Mar 30, 2016 at 8:55 AM, Ismael Juma <ism...@juma.me.uk> wrote:

> I haven't had a chance to look at the KIP in detail, but a quick comment
> below.
>
> On Wed, Mar 30, 2016 at 4:49 PM, Dana Powers <dana.pow...@gmail.com>
> wrote:
> >
> > MetadataRequest v1: long-term / conceptually, I think a "null" topic list
> > aligns better with fetching all topics. Empty list aligns better with
> > fetching no topics. I recognize this means that empty list behaves
> > differently in v0 versus v1. But hey, what are protocol versions good for
> > if not changing behavior... :) API design comment. take it or leave it.
>
>
> Yes, I think empty should be "no topics" too. However, I would suggest
> using a boolean to indicate "all topics" and null should not be allowed (as
> it is now). I think this is a clearer API and it's similar to
> how org.apache.kafka.clients.Metadata works today.
>
> Ismael
>

Reply via email to