[Interest] CBOR Questions
thiago.macieira at intel.com
Wed Mar 6 17:22:53 CET 2019
On Wednesday, 6 March 2019 06:50:28 PST Jason H wrote:
> > - if it's QCborError::EndOfFile, wait for more data
> > - if it's QCborError::NoError, remove "offset" bytes from the beginning
> > of
> > the buffer and process the loaded map
> > - if it's anything else, give up
> That seems extremely CPU wasteful. While a QDataStream would know exactly
> when all the bytes are there and would parse the object in one go.
Yes, it's CPU intensive.
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.
> 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
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
More information about the Interest