[Development] QDataStream: blackbox or document all versions?

[Ulf Hermann]

On 09/25/2016 05:58 AM, Thiago Macieira wrote:
> A thread[1] on the interest mailing list started when someone asked for the
> docs for the current format of the QDataStream wire protocol, to which I
> replied that it doesn't exist as we don't maintain such docs.
>
> Long story short, we have two options: [...]

I see another option: Make QDataStream a good interchange format.
 From your reply on the interest mailing list:

> I also don't think the QDataStream binary format is particularly good for non-
> Qt purposes. It passes internals that are really about how Qt works, not meant
> for interchange of information. For example, QDate passes the Julian Day in
> 64-bit format -- who in the world exchanges data like that? One would expect
> the serialisation format of a date and time to be something like milliseconds
> since 1970, milliseconds since 1601 or a string format, like ISO 3337. It
> passes strings as UTF-16 encoded instead of encoding with UTF-8, which would
> in turn allow interchanging QString and QByteArray serialisation formats.
>
> It's also by default quite inefficient since it marshalls everything as big-
> endian, while most CPUs are little-endian. It has no support for indexing or
> random-access seeking. It can't be used as a DOM storage, like QJsonDocument
> can.

All of that, except for the default endianness, could be fixed on a per operator base. Changing the default endianness can also be done with minimal effort and would only require incrementing the data stream version. Considering this, QDataStream may at the moment not be very efficient, but it does have some potential. We could probably even change all the operators to read and write CBOR, and that would also only require a version change. The versioning allows us to adapt the wire format to whatever is needed now or in the future. I don't know any other data interchange format which can do this.

This doesn't change the implicit conversion problem that Marc mentioned, but at the moment I don't quite see a way to fix it without removing a lot of convenience for the user (that is, have the user specify the exact intended type for each serialization operation).

regards,
Ulf