Hi Simon,
The newtmgr header itself is direct binary — it’s the command
contents that are JSON. Newtmgr can accommodate other forms of
encoding. For the command contents we looked at protobufs, json or
direct binary:
- direct binary, while most efficient, becomes difficult to maintain,
for all the usual reasons: structure versioning/backwards compatibility,
ease of introspection, etc.
- protobufs are great, and (~10-15% more efficient, when you consider
compression), however, in order to decode them, you require structure
definitions to be shared on both ends.
- whereas json is easy to define and introspect/share data. Our thought
is that if we can make it work for BLE, then most other transports are
going to be equivalent, or have more capacity.
the Mynewt implementation of newtmgr is missing currently missing
compression of JSON data, as we’ve focused more on correctness than
efficiency. We should get a 40-50% efficiency win when we implement
compression on the JSON data.
we also may have to revisit the image upgrade commands with newtmgr. I
think we may want to add an option to stream the image contents binary
as well as JSON, to avoid having to base64 encode the image contents.
having a chunked binary transfer mode would be useful, i think.
Sterling
On 30 Jul 2016, at 13:07, Simon Ratner wrote:
Hi devs,
Wondering if there was a specific rationale for picking json as
payload
serialization protocol for newtmgr?
Cheers,
simon
