In up-rust we have recently introduced custom definitions of the uProtocol types and no longer directly use the protoc generated types in our API. I am currently reviewing the existing API of UMessage/UAttributes and have stumbled across a few functions that I consider obsolete and/or confusing.
The UAttributes spec currently defines several attributes as optional instead of explicitly defining a default value. My understanding is, that this basically comes from the fact that we originally used proto3 files to define these types and protobuf tries to be as efficient as possible by means of omitting fields that have their default value, e.g. uint32 typed fields having value 0.
This is also reflected in our custom Rust types, for example the time-to-live attribute is defined as Option<u32> instead of just u32. Client code retrieving the attribute is left alone with interpreting a value of None, though, because the spec is unclear about the meaning of a message that has no TTL defined.
My best guess is that by default, such a message should be considered to have a TTL of 0, which means that it never expires. An alternative interpretation might be that a processor can assume any reasonable TTL (e.g. 5 seconds) instead. However, this behavior is not defined explicitly.
To make the API more concise and to remove ambiguity, I suggest making the ttl field mandatory and define 0 as its default value. Similarly, I suggest making priority mandatory with a default value of CS1, and to make the commstatus property of Response messages mandatory with a default value of OK.
Note that this has no direct impact on how the message is being encoded on the wire because the transports already are free to define the mapping of message attributes to their particular packet data units (PDU).
In up-rust we have recently introduced custom definitions of the uProtocol types and no longer directly use the protoc generated types in our API. I am currently reviewing the existing API of UMessage/UAttributes and have stumbled across a few functions that I consider obsolete and/or confusing.
The UAttributes spec currently defines several attributes as optional instead of explicitly defining a default value. My understanding is, that this basically comes from the fact that we originally used proto3 files to define these types and protobuf tries to be as efficient as possible by means of omitting fields that have their default value, e.g. uint32 typed fields having value 0.
This is also reflected in our custom Rust types, for example the time-to-live attribute is defined as
Option<u32>instead of justu32. Client code retrieving the attribute is left alone with interpreting a value ofNone, though, because the spec is unclear about the meaning of a message that has no TTL defined.My best guess is that by default, such a message should be considered to have a TTL of 0, which means that it never expires. An alternative interpretation might be that a processor can assume any reasonable TTL (e.g. 5 seconds) instead. However, this behavior is not defined explicitly.
To make the API more concise and to remove ambiguity, I suggest making the ttl field mandatory and define 0 as its default value. Similarly, I suggest making priority mandatory with a default value of
CS1, and to make the commstatus property of Response messages mandatory with a default value ofOK.Note that this has no direct impact on how the message is being encoded on the wire because the transports already are free to define the mapping of message attributes to their particular packet data units (PDU).