Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

[Ismael Juma <is...@juma.me.uk>]

Coming back to this, see below.

On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io> wrote:

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

I think this one seems to be the least controversial part of the proposal.
And I agree with this suggestion.

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

It seems like there is no clear winner, so I am OK with this too.

Given the release plan for 0.10.0.0 that is being voted on, I think we
should make a decision on this one way or another very soon.

Ismael

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

[Becket Qin <be...@gmail.com>]

Hi Jason,

Yes, 0.9 clients should still work with 0.10 brokers.

Thanks,

Jiangjie (Becket) Qin

On Mon, Mar 7, 2016 at 4:10 PM, Jason Gustafson <ja...@confluent.io> wrote:

> +users
>
> On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> > Hey Ismael,
> >
> > Thanks for bringing this up again. Just a quick question: if we do #1,
> > then there's no way that a user binary could work against both 0.9 and
> 0.10
> > of kafka-clients, right? I'm not sure if that is much of a problem, but
> may
> > cause a little pain if a user somehow depends transitively on different
> > versions. Excluding this change, would we otherwise expect
> > kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> > KIP-32 continued to support the old message format, but I could be wrong.
> >
> > -Jason
> >
> > On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> >> Coming back to this, see below.
> >>
> >> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
> >> wrote:
> >>
> >> >
> >> > 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.
> >> >
> >>
> >> I think this one seems to be the least controversial part of the
> proposal.
> >> And I agree with this suggestion.
> >>
> >> 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.
> >> >
> >>
> >> It seems like there is no clear winner, so I am OK with this too.
> >>
> >> Given the release plan for 0.10.0.0 that is being voted on, I think we
> >> should make a decision on this one way or another very soon.
> >>
> >> Ismael
> >>
> >
> >
>

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

[Becket Qin <be...@gmail.com>]

Hi Jason,

Yes, 0.9 clients should still work with 0.10 brokers.

Thanks,

Jiangjie (Becket) Qin

On Mon, Mar 7, 2016 at 4:10 PM, Jason Gustafson <ja...@confluent.io> wrote:

> +users
>
> On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> > Hey Ismael,
> >
> > Thanks for bringing this up again. Just a quick question: if we do #1,
> > then there's no way that a user binary could work against both 0.9 and
> 0.10
> > of kafka-clients, right? I'm not sure if that is much of a problem, but
> may
> > cause a little pain if a user somehow depends transitively on different
> > versions. Excluding this change, would we otherwise expect
> > kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> > KIP-32 continued to support the old message format, but I could be wrong.
> >
> > -Jason
> >
> > On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
> >
> >> Coming back to this, see below.
> >>
> >> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
> >> wrote:
> >>
> >> >
> >> > 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.
> >> >
> >>
> >> I think this one seems to be the least controversial part of the
> proposal.
> >> And I agree with this suggestion.
> >>
> >> 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.
> >> >
> >>
> >> It seems like there is no clear winner, so I am OK with this too.
> >>
> >> Given the release plan for 0.10.0.0 that is being voted on, I think we
> >> should make a decision on this one way or another very soon.
> >>
> >> Ismael
> >>
> >
> >
>

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

[Jason Gustafson <ja...@confluent.io>]

+users

On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io> wrote:

> Hey Ismael,
>
> Thanks for bringing this up again. Just a quick question: if we do #1,
> then there's no way that a user binary could work against both 0.9 and 0.10
> of kafka-clients, right? I'm not sure if that is much of a problem, but may
> cause a little pain if a user somehow depends transitively on different
> versions. Excluding this change, would we otherwise expect
> kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> KIP-32 continued to support the old message format, but I could be wrong.
>
> -Jason
>
> On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
>> Coming back to this, see below.
>>
>> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
>> wrote:
>>
>> >
>> > 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.
>> >
>>
>> I think this one seems to be the least controversial part of the proposal.
>> And I agree with this suggestion.
>>
>> 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.
>> >
>>
>> It seems like there is no clear winner, so I am OK with this too.
>>
>> Given the release plan for 0.10.0.0 that is being voted on, I think we
>> should make a decision on this one way or another very soon.
>>
>> Ismael
>>
>
>

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

[Jason Gustafson <ja...@confluent.io>]

+users

On Mon, Mar 7, 2016 at 4:09 PM, Jason Gustafson <ja...@confluent.io> wrote:

> Hey Ismael,
>
> Thanks for bringing this up again. Just a quick question: if we do #1,
> then there's no way that a user binary could work against both 0.9 and 0.10
> of kafka-clients, right? I'm not sure if that is much of a problem, but may
> cause a little pain if a user somehow depends transitively on different
> versions. Excluding this change, would we otherwise expect
> kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
> KIP-32 continued to support the old message format, but I could be wrong.
>
> -Jason
>
> On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:
>
>> Coming back to this, see below.
>>
>> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
>> wrote:
>>
>> >
>> > 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.
>> >
>>
>> I think this one seems to be the least controversial part of the proposal.
>> And I agree with this suggestion.
>>
>> 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.
>> >
>>
>> It seems like there is no clear winner, so I am OK with this too.
>>
>> Given the release plan for 0.10.0.0 that is being voted on, I think we
>> should make a decision on this one way or another very soon.
>>
>> Ismael
>>
>
>

Re: [DISCUSS] KIP-45 Standardize all client sequence interaction on j.u.Collection.

[Jason Gustafson <ja...@confluent.io>]

Hey Ismael,

Thanks for bringing this up again. Just a quick question: if we do #1, then
there's no way that a user binary could work against both 0.9 and 0.10 of
kafka-clients, right? I'm not sure if that is much of a problem, but may
cause a little pain if a user somehow depends transitively on different
versions. Excluding this change, would we otherwise expect
kafka-clients-0.9 to work with an 0.10 broker? I thought the changes for
KIP-32 continued to support the old message format, but I could be wrong.

-Jason

On Mon, Mar 7, 2016 at 3:29 PM, Ismael Juma <is...@juma.me.uk> wrote:

> Coming back to this, see below.
>
> On Wed, Jan 27, 2016 at 9:01 PM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> >
> > 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.
> >
>
> I think this one seems to be the least controversial part of the proposal.
> And I agree with this suggestion.
>
> 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.
> >
>
> It seems like there is no clear winner, so I am OK with this too.
>
> Given the release plan for 0.10.0.0 that is being voted on, I think we
> should make a decision on this one way or another very soon.
>
> Ismael
>