-
Notifications
You must be signed in to change notification settings - Fork 14
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
Move to core-api UPayload data model #41
Conversation
Pulling from snapshot till the other project is merged #40
import org.eclipse.uprotocol.uri.serializer.LongUriSerializer; | ||
import org.eclipse.uprotocol.v1.*; | ||
import org.eclipse.uprotocol.v1.UUri; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we have the version in the package name. makes upgrading even messier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to ensure that if/when we go to a non-backwards compatible version of uProtocol (ex. v1) that we have differentiate the data model between them like we do for uSubscription, uDiscovery, etc...
@@ -64,8 +73,10 @@ public CompletableFuture<UPayload> invokeMethod(UUri topic, UPayload payload, UA | |||
public CompletableFuture<UPayload> invokeMethod(UUri topic, UPayload payload, UAttributes attributes) { | |||
Status status = Status.newBuilder().setCode(Code.INVALID_ARGUMENT_VALUE).setMessage("boom").build(); | |||
Any any = Any.pack(status); | |||
UPayload data = new UPayload(any.toByteArray(), UPayloadFormat.UPAYLOAD_FORMAT_PROTOBUF); | |||
|
|||
UPayload data = UPayload.newBuilder() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
personally I prefer working with the constructors and not verbose builders if they are not really needed.
I do understand why you wanted to define the payload as a protobuf object
But then again - at the end of the day, uTransport gets a byte[], so are we not creating a protobuf object whose job is transport and then just translating it into the real transport object which is the byte[]
what value is achieved by the payload being a protobuf object?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UPayload is to wrap the data + metadata and keep it separate from the message attributes (priority, addressing, timeout, etc...). Yes you are right for the data but the metadata will most likely be mapped somehow into the local transport (HTTP header, zenoh header, etc...).
the benefit of the UPayload being in proto is the consistently for all data types (and the UPayloadFormat as well).
Pulling from snapshot till the other project is merged
#40