Skip to content
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

Merged
merged 3 commits into from
Nov 20, 2023
Merged

Move to core-api UPayload data model #41

merged 3 commits into from
Nov 20, 2023

Conversation

stevenhartley
Copy link

Pulling from snapshot till the other project is merged

#40

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;
Copy link
Contributor

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

Copy link
Author

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()
Copy link
Contributor

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?

Copy link
Author

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).

@stevenhartley stevenhartley merged commit ea94d1b into main Nov 20, 2023
3 checks passed
@stevenhartley stevenhartley deleted the upayload branch February 20, 2024 12:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants