This provides an API for setting configuration items that are common to all nodes, and getting their current configuration state from a node. It is a simple, fixed-size format that is easier to implement and debug than GetSet. This proposal uses byte-aligned, constant-size fields, and groups together important and universal settings.
Reasons why I think this will be easier to use:
GetSet has padding bits
GetSet uses the variable-length name field. Strings are a bit awkward to work with here, and aren't required.
GetSet's Value and NumericalValue fields are variable-length; especially for handling string format.
It is unclear from its spec how GetSet's set vs get, and expected acknowledgement format work.
Overall, managing GetSet's alignment has nested levels of bit-level, variable-length alignment, which is tricky to implement and debug, given the simple nature of its task. This applies to both serializing and deserializing.
I am open to ideas on data type IDs, fields to add, etc. A notable downside of this proposal is that the format is not very efficient due to byte-level packing, including of fields that have 2 bits. Given this message is expected to be sent infrequently, and is still compact (less than a full legacy frame), I think this is a worthwhile tradeoff.
This provides an API for setting configuration items that are common to all nodes, and getting their current configuration state from a node. It is a simple, fixed-size format that is easier to implement and debug than
GetSet
. This proposal uses byte-aligned, constant-size fields, and groups together important and universal settings.Reasons why I think this will be easier to use:
GetSet
has padding bitsGetSet
uses the variable-lengthname
field. Strings are a bit awkward to work with here, and aren't required.GetSet
'sValue
andNumericalValue
fields are variable-length; especially for handling string format.GetSet
's set vs get, and expected acknowledgement format work.Overall, managing
GetSet
's alignment has nested levels of bit-level, variable-length alignment, which is tricky to implement and debug, given the simple nature of its task. This applies to both serializing and deserializing.I am open to ideas on data type IDs, fields to add, etc. A notable downside of this proposal is that the format is not very efficient due to byte-level packing, including of fields that have 2 bits. Given this message is expected to be sent infrequently, and is still compact (less than a full legacy frame), I think this is a worthwhile tradeoff.