[Interest] QCborValue and Qt types

[Thiago Macieira]

On Sunday, 2 December 2018 09:12:15 PST Konstantin Shegunov wrote:
> Thanks for the heads up.
> 
> On Sat, Dec 1, 2018 at 7:43 PM Thiago Macieira <thiago.macieira at intel.com>
> wrote:
> > Yes and no. See the attached draft spec (tag numbers are outdated) for a
> > few
> > types I had been thinking of and already have an implementation for. Which
> > also reminds me I needed to send them to the CBOR IETF group for review.
> 
> Looked them up, they seem fine to me. Hopefully the IETF agree.
> 
> > I was thinking of sticking at first to QtCore types, so QImage will not be
> > included. I'm not even sure how we could add support for types in other
> > libraries; possibly you'll need to register a serialisation and
> > deserialisation function like qRegisterStreamOperators does.
> 
> Yes, this is how I imagined it initially. I suspect this is how it's done
> currently for registered meta types?

Again "yes and no". QtCore knows a little about the existence of QtGui and 
QtWidgets, so qvariant.cpp and qmetatype.cpp have provisions to store the 
hooks for the operations on types from those libraries. It's messy code and 
has been a source of problems. For example, if v1 is a QtCore type and v2 is a 
QtGui type, v1 == v2 might be true but v2 == v1 might not. Messy. Jędrzej 
mentioned once he has a nice idea on how to fix it but couldn't fit it in the 
margins of his diary.

But if we do support CBOR serialisation and deserialisation of types from 
QtGui, internally QCborValue would have a couple of callbacks for QtGui to 
post-process a decoded CBOR tag + payload.

Note also that the vast majority of standardiseable types from QtGui are also 
types which we're discussing to move from QtGui to a non-GUI library. 
Previously I objected to having them in QtCore with the rationale that "QtCore 
is not the kitchen sink", but I'm open to new arguments.

That leaves the non-standardiseable ones, like QCursor, QTextFormat or QPen. 
And yet we'd like to transmit them over CBOR. The only question is how. One 
simple way is to reserve a metatype for "Qt 5 type" (or Qt 6), whose payload 
is an array consisting of an integer (the metatype ID) and a binary payload. 
That binary payload may be the same as QDataStream currently carries, or an 
improvement thereof. But if we're going to do this, we will need to be better 
at documenting the different payloads.

Or we just reserve a tag for "QDataStream", consisting of version number and 
binary payload.

Or both.

> For the latter it's harder to judge, but probably it would be necessary to
> use some kind of device-independent pixel format. If data encoding can be
> used (e.g. png/jpeg) all the better, but even raw pixels should serve fine.
> Granted this means that QPixmap and QBitmap may need to be converted to
> QImage and vice versa, but I really see no clever way around it, at least
> off the top of my head. That is unless it's acceptable to encode
> meta-information like bit depth and such in the data stream, then maybe
> some small optimization could be possible. Probably this'd mean that the
> user will need to "know" beforehand what exact kind of object was put in
> the cbor document, but without a schema I'd say that's probably to be
> expected.

I think this is a good opportunity for us and the larger IoT community to 
discuss how to best transport such data. Compressing as JPEG or PNG may be 
good and well, but so is just plain transmitting of RGB/RGBA or YUV or YCbCr 
data. Imagine a fingerprint scanner device that wants to transmit its reading 
and let's say it's a 96x256 grayscale pixmap[1]. The device may not have 
sufficient processing power to compress the image as PNG, but 24576 bytes may 
be totally doable, even if it takes 26 UDP packets (960 payload bytes per 
1024-byte datagram).

[1] I have no idea if this is a good representation nor am I saying anyone 
should try this for their own devices without further investigation. This is 
just for the sake of illustration.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center