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