since i am dealing with CayenneLPP quite a bit, i see some serious downsides:
any Change/Extension for another IPSO Object/Property will render any decoder that does not understand the changes unusable.
If the appropriate decoder does not know about each single object that had been sent, i will fail, since it also does not know about the size of the unsupported object.
To circumvent this, i have a suggestion (among others) to improve this protocol:
Do we need 256 Channels? Otherwise, we could limit that to 16 Channels and use other 4 bit for size information. I was thinking about this: 0 - 11 encodes the size if the data object directly. 12 could mean boolean false, 13 boolean true, 14 flags (a flag byte will follow after the type byte, see BIPSO spec), 15 size (a size byte will follow after the type byte). For flags we might define a fixed size for values (e.g. 16 bit value) so the decoder knows how far it shall advance within the byte buffer, if the appropriate object is not understood.
To support extended/more types we could reserve types values starting from 240 (or 248) to indicate, that an extType byte will follow after the type byte (or the size/flags byte if indicated). This would allow another 16 256 types (or 8 256).
These two changes would perfectly allow anything that comes up in the future and also allows encoders to be backwards compatible with previous protocol versions.
Additionally, boolean data can be encoded directly without spending another byte.
The downside: we would be limited to 16 channels (which is probably enough) if not adding another byte to the payload.
Hi again,
since i am dealing with CayenneLPP quite a bit, i see some serious downsides: any Change/Extension for another IPSO Object/Property will render any decoder that does not understand the changes unusable. If the appropriate decoder does not know about each single object that had been sent, i will fail, since it also does not know about the size of the unsupported object.
To circumvent this, i have a suggestion (among others) to improve this protocol:
These two changes would perfectly allow anything that comes up in the future and also allows encoders to be backwards compatible with previous protocol versions. Additionally, boolean data can be encoded directly without spending another byte. The downside: we would be limited to 16 channels (which is probably enough) if not adding another byte to the payload.
What do you think?