[Interest] CBOR Questions

[Jason H]

> If you know the size of the payload prior to sending it, you can simply send 
> it using CBOR itself. That is, you'll send pairs of unsigned numbers and maps. 
> And both QCborValue and QCborStreamReader need the entire number to have 
> arrived to parse anything: it's always all or nothing. More importantly, 
> QCborValue allocates no memory to store a simple number.
> 
> Or you can decide to store it as a 16- or 32-bit number, with a specific 
> endianness. I'd use <qendian.h> for that, instead of QDataStream. You'd 
> accomplish the same thing, but with far less memory consumption.
> 
> > But short of that, it seems maybe like we need a API that has update() like
> > a Hashing algorithm, and a way to return a list of top-level objects with a
> > function that much implements the loop with the logic you expressed.
> 
> QCborStreamReader can resume reads. The unit test even has that. 
> Unfortunately, it's a bit cumbersome.
> 
> The API for QCborValue will come.

Excellent

> > I'm not a fan of keep "trying until it works". Such protocols are never
> > good. HTTP has content-length, or chunked encoding, but there's no "keep
> > trying until it works" header. I realize this is more an issue with the
> > CBOR standard not having a top-level item sentinel, and not a Qt
> > implementation thing.
> 
> Again, if you know the length from other means, you can just wait until you 
> have it.

Well one end knows it, the sending end that serialized it. This after reading the standards, this seems to be an assumption, the the generation of data will be on the lower-power leaf nodes of the network. But the lengths need to be communicated to the receiver. For CoAP, it is assuming packet length-header size is the payload. Thniag, the use of CBOR prefix object to indicate next object length is a clever hack. These lengths do vary, but at least you won't be parsing whole object trees repeatedly, you'll need at most parse 5 bytes:

1A 00752228 # unsigned(7676456)
19 1938 # unsigned(6456)
18 38 # unsigned(56)

So thanks for the suggestion. I will be implementing it!

Still seems like a length-indicated CBOR data stream would be a good idea though. At least with your suggested approach it can all be done in CBOR.

Thanks!