A last reminder :(
On Sun, Oct 15, 2023 at 1:25 PM Jack Tomy wrote:
> Hey contributors,
>
> Please vote or veto the proposal.
>
> Please don't ghost. Humble request.
>
> Thanks
>
> On Thu, Sep 28, 2023 at 7:23 AM Jack Tomy wrote:
>
>> Bumping up.
>>
>> On Sun, Sep 17, 2023 at 9:34 AM Jack
Hey contributors,
Please vote or veto the proposal.
Please don't ghost. Humble request.
Thanks
On Thu, Sep 28, 2023 at 7:23 AM Jack Tomy wrote:
> Bumping up.
>
> On Sun, Sep 17, 2023 at 9:34 AM Jack Tomy wrote:
>
>> Hey Ismael, Sagar and everyone,
>>
>> Sorry I seem to have interpreted
Bumping up.
On Sun, Sep 17, 2023 at 9:34 AM Jack Tomy wrote:
> Hey Ismael, Sagar and everyone,
>
> Sorry I seem to have interpreted the thread wrong. Before we go ahead with
> the DTO based approach I have few reasons not to go with it.
> a. It is not following the pattern we are following
Hey Ismael, Sagar and everyone,
Sorry I seem to have interpreted the thread wrong. Before we go ahead with
the DTO based approach I have few reasons not to go with it.
a. It is not following the pattern we are following today. But here I agree
that patterns are to be changed for good.
b. The
Hey Jack,
The way I interpreted this thread, it seems like there's more alignment on
the DTO based approach. I spent some time on the suggestion that Ismael had
regarding the usage of ProducerRecord. Did you get a chance to look at the
reply I had posted and whether that makes sense? Also,
Hey everyone,
As I see devs favouring the current style of implementation, and that is
inline with existing code. I would like to go ahead with the same approach
as mentioned in the KIP.
Can I get a few more votes so that I can take the KIP forward.
Thanks
On Sun, Aug 27, 2023 at 1:38 PM
Hi Ismael,
Thanks for pointing us towards the direction of a DTO based approach. The
AdminClient examples seem very neat and extensible in that sense.
Personally, I was trying to think only along the lines of how the current
Partitioner interface has been designed, i.e having all requisite
A more concrete question: did we consider having the method `partition`
take `ProduceRecord` as one of its parameters and `Cluster` as the other?
Ismael
On Sat, Aug 26, 2023 at 12:50 PM Greg Harris
wrote:
> Hey Ismael,
>
> > The mention of "runtime" is specific to Connect. When it comes to
>
Hey Ismael,
> The mention of "runtime" is specific to Connect. When it comes to clients,
one typically compiles and runs with the same version or runs with a newer
version than the one used for compilation. This is standard practice in
Java and not something specific to Kafka.
When I said "older
Hi Greg,
The mention of "runtime" is specific to Connect. When it comes to clients,
one typically compiles and runs with the same version or runs with a newer
version than the one used for compilation. This is standard practice in
Java and not something specific to Kafka.
With regards to the
Hey Ismael,
Thank you for clarifying where the DTO pattern is used already, I did
not have the admin methods in mind.
> With the DTO approach, you don't create a new DTO, you simply add a new
> overloaded constructor and accessor to the DTO.
With this variant, partitioner implementations would
Hi Greg,
The point is that the approach proposed here introduces complexity forever.
Each new user of this interface that needs access to the parameters not
exposed originally needs to implement the abstract method with an empty
implementation and it needs to override whichever additional default
Hey Jack,
The design of this KIP is also consistent with the way header support
was added to Connect:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-440%3A+Extend+Connect+Converter+to+support+headers
I think making argument for precedent here is reasonable.
Hi Ismael,
Can you expand what
Hi Ismael,
That would be totally different from the pattern currently being followed
in all the interfaces, for example serializer.
I personally don't favour that either. Let's see if the community has any
opinions on the same.
Hey everyone, please share your thoughts on using a DTO instead of
Hi Jack,
I mean a DTO. That means you can add additional parameters later without
breaking compatibility. The current proposal would result in yet another
method each time we need to add parameters.
Ismael
On Sun, Aug 20, 2023 at 4:53 AM Jack Tomy wrote:
> Hey Ismael,
>
> Are you suggesting
Hey Ismael,
Are you suggesting to pass a param like a DTO or you are suggesting to pass
the record object?
I would also like to hear other devs' opinions on this as I personally
favour what is done currently.
On Thu, Aug 17, 2023 at 9:34 AM Ismael Juma wrote:
> Hi,
>
> Thanks for the KIP. The
Hi,
Thanks for the KIP. The problem outlined here is a great example why we
should be using a record-like structure to pass the parameters to a method
like this. Then we can add more parameters without having to introduce new
methods. Have we considered this option?
Ismael
On Mon, Aug 7, 2023
+1 (non-binding)
Thanks for your KIP!
From: dev@kafka.apache.org At: 08/16/23 04:48:13 UTC-4:00To:
dev@kafka.apache.org
Subject: Re: [VOTE] KIP-953: partition method to be overloaded to accept
headers as well.
Thanks Sagar and Chris for your votes. I will add the details Chris has
asked for
Thanks Sagar and Chris for your votes. I will add the details Chris has
asked for to the KIP.
Hey everyone,
Please consider this as a gentle reminder.
On Sat, Aug 12, 2023 at 10:48 AM Chris Egerton
wrote:
> Hi Jack,
>
> +1 (binding)
>
> Some friendly, non-blocking suggestions:
>
> - IMO it's
Hi Jack,
+1 (binding)
Some friendly, non-blocking suggestions:
- IMO it's still worth specifying that the headers will be read-only; this
clarifies the intended API contract both for reviewers of the KIP who
haven't read the GitHub PR yet, and for developers who may leverage this
new method
-
Hey jack ,
+1 (non binding)
Sagar.
On Sat, 12 Aug 2023 at 8:04 AM, Jack Tomy wrote:
> Hey everyone,
>
> Please consider this as a gentle reminder.
>
> On Mon, Aug 7, 2023 at 5:55 PM Jack Tomy wrote:
>
> > Hey everyone.
> >
> > I would like to call for a vote on KIP-953: partition method to
Hey everyone,
Please consider this as a gentle reminder.
On Mon, Aug 7, 2023 at 5:55 PM Jack Tomy wrote:
> Hey everyone.
>
> I would like to call for a vote on KIP-953: partition method to be
> overloaded to accept headers as well.
>
> KIP :
>
Hey everyone.
I would like to call for a vote on KIP-953: partition method to be
overloaded to accept headers as well.
KIP :
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424937
Discussion thread :
https://lists.apache.org/thread/0f20kvfqkmhdqrwcb8vqgqn80szcrcdd
Thanks
--
23 matches
Mail list logo
