You could choose to turn QDataStream into a black-box, but I think there
should be a white-box alternative which has to be
1/ as efficient : binary format
2/ as easy to use : QDataStream is able to serialize any type with the help
of qRegisterMetaTypeStreamOperators
3/ as generic : it should be able to use any QIODevice for transport/storage

1/ discards XML and JSON, and 3/ discards QSettings and D-Bus. I don't know
CBOR, but it seems an interesting alternative.

Eric Lemanissier

Le dim. 25 sept. 2016 à 05:59, Thiago Macieira <[email protected]>
a écrit :

> 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:
>
> that can read QDataStream is QDataStream. That means removing the
> Option 1: claim QDataStream is a blackbox and tell people that the only
> thing
> that can read QDataStream is QDataStream. That means removing the
> documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't
> want
> people getting any ideas that they could write their own decoders or
> encoders.
>
> Option 2: the opposite, saying that reading QDataStream's output is fine
> from
> non-Qt code and it's fine to write data that QDataStream should read. This
> means extending the documentation to cover ALL 17 wire formats (including
> bugs) and keeping it up to date whenever someone modifies the format.
>
>
> I am in favour of Option 1 because I really don't think QDataStream is a
> good
> format for exchanging data with non-Qt code. It's designed first and
> foremost
> for Qt's own internal data formats (sometimes even depending on internal
> details), the marshalling of certain types in certain versions is buggy and
> lossy. Instead, people should find a better transport format for their
> data, of
> which we already have in Qt:
>
>         XML
>         JSON
>         D-Bus
>         QSettings (to an extent)
>
> And I can add CBOR support if we want to.
>
> [1]
> http://lists.qt-project.org/pipermail/interest/2016-September/024387.html
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
>
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to