A summary of the changes from previous version can be seen under Public
Interfaces --> UPDATE
On Sat, Jun 5, 2021 at 1:42 PM Josep Prat wrote:
> Hi all,
>
> During the vote thread there was a request to extend this KIP to be
> aligned with https://issues.apache.org/jira/browse/KAFKA-12370.
>
Hi all,
During the vote thread there was a request to extend this KIP to be aligned
with https://issues.apache.org/jira/browse/KAFKA-12370.
Disucssion point is here:
https://lists.apache.org/x/thread.html/rafa347f2c0f0bddb253c1ddc8d2817d1f04d500bb96366a4f6ec9482@%3Cdev.kafka.apache.org%3E
Hi all,
I managed to update the KIP to include the changes Bruno proposed and also
extended it to include the migration of ThreadMetadata to an interface plus
internal implementation. Please share any feedback or problems you might
see with this approach.
As the deadline for KIPs approaches, I
Hi Bruno,
Thanks for your feedback. I think it makes sense to add the hasCode() and
equals() definitions with its guarantees on the interface level.
I'm also inclined to add the ThreadMetadata conversion to an interface into
this KIP. Implementation-wise is not that different. And on API level
Hi Josep,
Thank you for the KIP!
Specifying TaskMetadata as an interface lifts the guarantee that
equals() and hashCode() on the TaskMetadata return consistent values for
the same content. Note that the current TaskMetadata implements both
methods, so theoretically users might already rely
I'm starting to wonder if we should make ThreadMetadata follow the same
path as TaskMetadata and be converted to an interface + internal
implementation. What are your thoughts?
Thanks in advance,
Josep
On Mon, May 31, 2021 at 12:10 PM Josep Prat wrote:
> Hi there,
> While looking closely at
Hi there,
While looking closely at the classes affected by this change, I realized
that ThreadMetadata has a reference in its public API to the soon to be
deprecated TaskMetadata. For this reason, I updated the KIP to reflect that
2 more changes are needed for this KIP:
ThreadMetadata:
- Deprecate
Hi there,
I updated the KIP page with Sophie's feedback. As she already mentioned,
the intention would be to include this KIP in release 3.0.0 so we can avoid
a deprecation cycle for the getTaskID method introduced in KIP-740, I hope
I managed to capture this in the KIP description.
Just adding
Hi Sophie,
Thanks for the feedback, I'll update the KIP tomorrow with your feedback.
They are all good points, and you are right, my phrasing could be
misleading.
Best,
On Thu, May 27, 2021 at 10:02 PM Sophie Blee-Goldman
wrote:
> Thanks for the KIP! I'm on board with the overall proposal,
Thanks for the KIP! I'm on board with the overall proposal, just a few
comments:
1) The motivation section says
TaskMetadata should have never been a class available for the general
> public, but more of an internal class
which is a bit misleading as it seems to imply that TaskMetadata itself
I deliberately picked the most conservative approach of creating a new
Interface, instead of transforming the current class into an interface.
Feedback is most welcome!
Best,
On Thu, May 27, 2021 at 10:26 AM Josep Prat wrote:
> Hi there,
> I would like to propose KIP-744, to introduce
Hi there,
I would like to propose KIP-744, to introduce TaskMetadata as an interface,
to keep the its implementation as internal use.
This KIP can be seen as a spin-off of KIP-740.
https://cwiki.apache.org/confluence/x/XIrOCg
Best,
--
Josep Prat
*Aiven Deutschland GmbH*
Immanuelkirchstraße
12 matches
Mail list logo
