-
Notifications
You must be signed in to change notification settings - Fork 172
Added the field localCorrelationData to MqttPublish for better flow-handling in reactive-APIs #546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -77,6 +77,12 @@ public interface Mqtt3Publish extends Mqtt3Message { | |
*/ | ||
boolean isRetain(); | ||
|
||
/** | ||
* @return the optional local correlation data of this Publish message. This data is never propagated and kept | ||
* locally for correlation. | ||
*/ | ||
Object localCorrelationData(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This API needs to be discussed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean the usage of object (yep, could replace it with a generic but that would change general signature of the class) or something else? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I do not like a generic here. But maybe there would be a case for creating a more sophisticated structure like for user properties. Having just plain Object there is not very expandable. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @YannickWeber any objections to merging this and then punting the improvement (that may or may not be needed) for a future date? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes I have objections. This is API, API can only change in major versions, therefore we need to be very cautious what we are adding and need to double check for expandability and clarity to make it future-proof. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
One addition, I agree on this point completely. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with moving cautiously, just to provide some context: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Of course we can add API in minor versions, but we can only remove methods in major versions. Therefore, I want us to be very careful about API design, as we can't easily correct potential API issues.
I would argue that API stability and caution is of high importance independent of where it is used. My suggestion would be to not return an Object but rather add an Interface There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An unsafe cast can be avoided with an instanceof, which got a lot nicer with recent Java-versions. From a type-perspective it would be best to introduce a generic, like Ractor-Kafka is doing it (https://github.com/reactor/reactor-kafka/blob/main/src/main/java/reactor/kafka/sender/SenderRecord.java#L30). Everything without a generic will require an unsafe cast at some point. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A final decision would be ideal. Let me know if there are any other thoughts.
codepitbull marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
/** | ||
* Acknowledges this Publish message. | ||
* | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -109,6 +109,12 @@ public interface Mqtt5Publish extends Mqtt5Message { | |
*/ | ||
@NotNull Mqtt5UserProperties getUserProperties(); | ||
|
||
/** | ||
* @return the optional local correlation data of this Publish message. This data is never propagated and kept | ||
* locally for correlation. | ||
*/ | ||
Object getLocalCorrelationData(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This API needs to be discussed.
codepitbull marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
/** | ||
* Acknowledges this Publish message. | ||
* | ||
|
Uh oh!
There was an error while loading. Please reload this page.