Rethinking serialization for Qt6

Arnaud Clère

Serialization is an old problem, still, we keep writing code to serialize C++ data in specific ways again and again. With Qt5 for instance, you may have to code: QDebug << to debug it, QDataStream << and >> to marshal it to another Qt application, use QSettings to make it persistent, QJson* or QXml* to convey it on the web, QCbor* for the IoT, and QAbstractModelItem for the DB/GUI. Even though such code needs to be customized here and there, it is mostly boilerplate code. So, can we make this simpler for Qt6?

Indeed, I will present a solution that enables to read/write C++ data from/to any of those APIs by defining a single function which can be easily customized to specific needs. Its runtime overhead being almost negligible, I will go on talking about many data formats from QDataStream to XML since that is where the actual performance/safety/interoperability tradeoffs are made. That should trigger an interesting discussion on the tradeoffs made by the only broadly implemented serialization for Qt types: QDataStream.

Finally, I hope to trigger enough interest from the community to review and polish this proposal, and to enable more serialization choices for most Qt6 types.

Notes

Slides presentation

• Json API is based on Cbor since a couple of weeks
• Serializing Qt data
• QValue/QValueStatus as an interface for serializing data,

 using:
   .record(),
   .bind() (with recursion inclued)

• Use reflections for getting the information related to the meta-object

Discussion

• What is the proposal for Qt6?

* Patch on Gerrit.
* Is this valuable?
* Start enabling CBorStreamWriter with te value() method, to provide
  the QValue interface.
* Flexibility and Safety are the base on this approach.

• What about performance?

 * Not much, there was tests with constexpr, but it was OK

• Is this Meta Data Format?

* Yes, the idea is to provide flexibility.

• Does it need to be runtime? What about compile time?
• What is you break up the patch?

* The idea could be to include this step-by-step.

• Boost serialization has a similar idea in place, what about it?

* Worth comparing it.
* Archive type provide some info.
* Less flexibility to provide some data types, like XML.

• protobuf could be a better solution.

* QDataStream, code is the schema.
* Move problem to another side, code to an external file.
  that still need to be managed on a central way.
  * What about the provisions that are provided?
   * There are protocols that handle version schemas.

• In Cbor, you habe additional checks for the data (protobuf doesn't)
• Tradeoff between performance, safety.