-
Notifications
You must be signed in to change notification settings - Fork 26
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
RpcClient::invokeMethod() passing CallOptions #69
Comments
@stevenhartley What about the message priority? Shouldn't that also be part of the CallOptions or is the priority fixed at CS4 for RPC requests? |
Good point, it needs to be CS4 at least but we need to be able to set it to priority other than CS4. @sophokles73 I was thinking that CallOptions should also be defined in proto, WDYT? |
sure, I would suggest to add it to attributes.proto so that it is easier to keep consistent. |
This ticket is linked to eclipse-uprotocol/up-core-api#107 that moves CallOptions to proto definition for consistency across all languages |
The following chance replaces UAttributes with CallOptions that are defined in uattributes.proto #69
* Update spec to match implementations The following chance replaces UAttributes with CallOptions that are defined in uattributes.proto #69 * Fix the link
Merged |
Align the spec with up-java and up-rust where we pass CallOptions in lieu of UAttributes to the method as the only attribute we need is the ttl and token as the other UAttributes can be auto-generated in the implementation of invokeMethod().
The text was updated successfully, but these errors were encountered: