Hey Matthias, Yeah, I think we mostly agree. I think if we think the new way is a lot better, then I agree keeping it deprecated for a long while then removing is a viable path. To me this case just seemed like a minor thing so the 1+ years of having a deprecated way in common use and a new way and the resulting confusion just seems unnecessary, especially since this is so much in the common path of the most basic kafka usage. My experience with other apis like MapReduce or Google Collections that did this was pretty negative.
Big time agreement that doing both is not the right thing to do. People aren't looking for 4 different ways of creating a ProducerRecord, that just generates confusion. -Jay On Mon, May 1, 2017 at 10:34 AM, Matthias J. Sax <matth...@confluent.io> wrote: > Hi, > > I am personally not a big fan of providing two APIs to do the same > thing. If we believe that one API is better than the other, we should > indicate this by deprecating the old API IMHO. > > Just my two cents. > > > -Matthias > > > On 4/30/17 11:05 PM, Michael Pearce wrote: > > See > > > > https://hc.apache.org/httpcomponents-client-ga/tutorial/html/fluent.html > > > > Doesn't cause much issue over there where you have a fluent api wrapper > for those who like that style, and the original more verbose api. > > > > Surely it would be better than removing a way of doing things that > everyone has got used to and built their code around ala constructors > approach. And simply provide a wrapper to provide a per field way of doing > things. > > > > > > > > > > > > Sent using OWA for iPhone > > ________________________________________ > > From: Stephane Maarek <steph...@simplemachines.com.au> > > Sent: Monday, May 1, 2017 6:37:44 AM > > To: dev@kafka.apache.org > > Subject: Re: [DISCUSS] KIP 141 - ProducerRecordBuilder Interface > > > > I’m not sure how people would feel about having two distinct methods to > build the same object? > > An API wrapper may be useful, but it doesn’t bring opinion about how one > should program, that’s just driven by the docs. > > I’m okay with that, but we need concensus > > > > > > On 1/5/17, 6:08 am, "Michael Pearce" <michael.pea...@ig.com> wrote: > > > > Why not, instead of deprecating or removing whats there, as noted, > its a point of preference, think about something that could wrap the > existing, but provide an api that for you is cleaner? > > > > e.g. here's a sample idea building on a fluent api way. (this wraps > the producer and producer records so no changes needed) > > > > https://gist.github.com/michaelandrepearce/ > de0f5ad4aa7d39d243781741c58c293e > > > > In future as new items further add to Producer Record, they just > become new methods in the fluent API, as it builds the ProducerRecord using > the most exhaustive constructor. > > > > > > > > ________________________________________ > > From: Matthias J. Sax <matth...@confluent.io> > > Sent: Saturday, April 29, 2017 6:52 PM > > To: dev@kafka.apache.org > > Subject: Re: [DISCUSS] KIP 141 - ProducerRecordBuilder Interface > > > > I understand that we cannot just break stuff (btw: also not for > > Streams!). But deprecating does not break anything, so I don't think > > it's a big deal to change the API as long as we keep the old API as > > deprecated. > > > > > > -Matthias > > > > On 4/29/17 9:28 AM, Jay Kreps wrote: > > > Hey Matthias, > > > > > > Yeah I agree, I'm not against change as a general thing! I also > think if > > > you look back on the last two years, we completely rewrote the > producer and > > > consumer APIs, reworked the binary protocol many times over, and > added the > > > connector and stream processing apis, both major new additions. So > I don't > > > think we're in too much danger of stagnating! > > > > > > My two cents was just around breaking compatibility for trivial > changes > > > like constructor => builder. I think this only applies to the > producer, > > > consumer, and connect apis which are heavily embedded in hundreds > of > > > ecosystem components that depend on them. This is different from > direct > > > usage. If we break the streams api it is really no big deal---apps > just > > > need to rebuild when they upgrade, not the end of the world at > all. However > > > because many intermediate things depend on the Kafka producer you > can cause > > > these weird situations where your app depends on two third party > things > > > that use Kafka and each requires different, incompatible versions. > We did > > > this a lot in earlier versions of Kafka and it was the cause of > much angst > > > (and an ingrained general reluctance to upgrade) from our users. > > > > > > I still think we may have to break things, i just don't think we > should do > > > it for things like builders vs direct constructors which i think > are kind > > > of a debatable matter of taste. > > > > > > -Jay > > > > > > > > > > > > On Mon, Apr 24, 2017 at 9:40 AM, Matthias J. Sax < > matth...@confluent.io> > > > wrote: > > > > > >> Hey Jay, > > >> > > >> I understand your concern, and for sure, we will need to keep the > > >> current constructors deprecated for a long time (ie, many years). > > >> > > >> But if we don't make the move, we will not be able to improve. > And I > > >> think warnings about using deprecated APIs is an acceptable price > to > > >> pay. And the API improvements will help new people who adopt > Kafka to > > >> get started more easily. > > >> > > >> Otherwise Kafka might end up as many other enterprise software > with a > > >> lots of old stuff that is kept forever because nobody has the > guts to > > >> improve/change it. > > >> > > >> Of course, we can still improve the docs of the deprecated > constructors, > > >> too. > > >> > > >> Just my two cents. > > >> > > >> > > >> -Matthias > > >> > > >> On 4/23/17 3:37 PM, Jay Kreps wrote: > > >>> Hey guys, > > >>> > > >>> I definitely think that the constructors could have been better > designed, > > >>> but I think given that they're in heavy use I don't think this > proposal > > >>> will improve things. Deprecating constructors just leaves > everyone with > > >>> lots of warnings and crossed out things. We can't actually > delete the > > >>> methods because lots of code needs to be usable across multiple > Kafka > > >>> versions, right? So we aren't picking between the original > approach > > >> (worse) > > >>> and the new approach (better); what we are proposing is a > perpetual > > >>> mingling of the original style and the new style with a bunch of > > >> deprecated > > >>> stuff, which I think is worst of all. > > >>> > > >>> I'd vote for just documenting the meaning of null in the > ProducerRecord > > >>> constructor. > > >>> > > >>> -Jay > > >>> > > >>> On Wed, Apr 19, 2017 at 3:34 PM, Stephane Maarek < > > >>> steph...@simplemachines.com.au> wrote: > > >>> > > >>>> Hi all, > > >>>> > > >>>> My first KIP, let me know your thoughts! > > >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP+ > > >>>> 141+-+ProducerRecordBuilder+Interface > > >>>> > > >>>> > > >>>> Cheers, > > >>>> Stephane > > >>>> > > >>> > > >> > > >> > > > > > The information contained in this email is strictly confidential and > for the use of the addressee only, unless otherwise indicated. If you are > not the intended recipient, please do not read, copy, use or disclose to > others this message or any attachment. Please also notify the sender by > replying to this email or by telephone (+44(020 7896 0011) and then delete > the email and any copies of it. Opinions, conclusion (etc) that do not > relate to the official business of this company shall be understood as > neither given nor endorsed by it. IG is a trading name of IG Markets > Limited (a company registered in England and Wales, company number > 04008957) and IG Index Limited (a company registered in England and Wales, > company number 01190902). Registered address at Cannon Bridge House, 25 > Dowgate Hill, London EC4R 2YA. Both IG Markets Limited (register number > 195355) and IG Index Limited (register number 114059) are authorised and > regulated by the Financial Conduct Authority. > > > > > > > >
