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



_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to