> > 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 >