>From the user code I see that uses the new consumer API so far, here are my
two cents:
1. For subscribe() and assign(), because we are doing an replacement,
taking either a List() or Collection() makes sense.
2. For seek(), pause(), resume(), it depends on how easily user can use
them.
If we take current interface, and user have a list of partitions to
pause(), what they can do is something like:
pause(patitionList.toArray());
If we change that to take a collection and user have only one partition
to pause. They have to do:
pause(new List<>(partition));
Personally I think the current interface handles both single partition
and a list of partitions better. It is not ideal that we have to adapt to
the interface. I just feel it is weirder to create a new list.
Thanks,
Jiangjie (Becket) Qin
On Wed, Jan 27, 2016 at 2:24 PM, Gwen Shapira <g...@confluent.io> wrote:
> I have a minor preference toward modifying the API.
> Because it is source-compatible and protocol-compatible, the only case that
> will break is if you use client code from one version but run with a JAR
> from a different version, which sounds like a pretty weird setup in
> general.
>
> Its not a strong preference though, I'll vote for either.
>
> On Wed, Jan 27, 2016 at 1:35 PM, Pierre-Yves Ritschard <p...@spootnik.org>
> wrote:
>
> >
> > Hi Jason,
> >
> > Thanks for weighing in on this. Here's my take:
> >
> > - I initially opted for overloading, but this met resistance (most
> > vocally from Jay Kreps). I don't have strong feelings either way (I
> > tend to prefer the current proposal without overloading but would
> > understand the need to add it back).
> > - The feedback I got around me (from an admittedly small population
> > sample) is that most people are thinking of migrating to 0.9.0.0. I
> > would wager that a very large majority of users are running production
> > apps on 0.8 clients and would thus not be impacted. The very recent
> > availability of the client libs would also indicate that those having
> > already switched to 0.9.0.0 client libs have a capacity to iterate
> fast.
> >
> > Jason Gustafson writes:
> >
> > > Hi Pierre,
> > >
> > > Thanks for your persistence on this issue. I've gone back and forth on
> > this
> > > a few times. The current API can definitely be annoying in some cases,
> > but
> > > breaking compatibility still sucks. We do have the @Unstable annotation
> > on
> > > the API, but it's unclear what exactly it means and I'm guessing most
> > users
> > > haven't even noticed it. In the end, I feel we should try harder to
> keep
> > > compatibility even if it means keeping some of the annoying usage. As
> an
> > > alternative, maybe we could do the following:
> > >
> > > 1. For subscribe() and assign(), change the parameter type to
> collection
> > as
> > > planned in the KIP. This is at least source-compatible, so as long as
> > users
> > > compile against the updated release, there shouldn't be any problems.
> > >
> > > 2. Instead of changing the signatures of the current pause/resume/seek
> > > APIs, maybe we can overload them. This keeps compatibility and supports
> > the
> > > more convenient collection usage, but the cost is some API bloat.
> > >
> > > In my opinion, the slightly increased surface area from overloading is
> > > worth the cost of keeping compatibility. Overloading is very common in
> > Java
> > > APIs, so there's no potential for confusion, and it has basically no
> > > maintenance overhead. However, I know others already expressed
> opposition
> > > to this, so if it's not agreeable, then I'm probably more inclined to
> > keep
> > > the current API. That said, it's not a strong preference. If the
> > consensus
> > > is to allow the breakage now, it doesn't seem like too big of a deal
> for
> > > users to update their code. It might be early enough that most users
> > > haven't finished (or perhaps haven't even started) migrating their code
> > to
> > > use the new consumer.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Jason
> > >
> > >
> > > On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <
> > p...@spootnik.org>
> > > wrote:
> > >
> > >>
> > >> I updated the KIP accordingly.
> > >>
> > >> Cheers,
> > >> - pyr
> > >>
> >
> >
>
