<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" style="font-size:12pt; color:#000000; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Do we need a way to tie A specific qdoc comment to the result of a specific autotest?</p>
<p><br>
</p>
<p>martin</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Development <development-bounces+martin.smith=qt.io@qt-project.org> on behalf of Thiago Macieira <thiago.macieira@intel.com><br>
<b>Sent:</b> Sunday, September 25, 2016 5:58:38 AM<br>
<b>To:</b> development@qt-project.org<br>
<b>Subject:</b> [Development] QDataStream: blackbox or document all versions?</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">A thread[1] on the interest mailing list started when someone asked for the
<br>
docs for the current format of the QDataStream wire protocol, to which I <br>
replied that it doesn't exist as we don't maintain such docs.<br>
<br>
Long story short, we have two options:<br>
<br>
Option 1: claim QDataStream is a blackbox and tell people that the only thing <br>
that can read QDataStream is QDataStream. That means removing the <br>
documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't want <br>
people getting any ideas that they could write their own decoders or encoders.<br>
<br>
Option 2: the opposite, saying that reading QDataStream's output is fine from <br>
non-Qt code and it's fine to write data that QDataStream should read. This <br>
means extending the documentation to cover ALL 17 wire formats (including <br>
bugs) and keeping it up to date whenever someone modifies the format.<br>
<br>
<br>
I am in favour of Option 1 because I really don't think QDataStream is a good <br>
format for exchanging data with non-Qt code. It's designed first and foremost <br>
for Qt's own internal data formats (sometimes even depending on internal <br>
details), the marshalling of certain types in certain versions is buggy and <br>
lossy. Instead, people should find a better transport format for their data, of <br>
which we already have in Qt:<br>
<br>
        XML<br>
        JSON<br>
        D-Bus<br>
        QSettings (to an extent)<br>
<br>
And I can add CBOR support if we want to.<br>
<br>
[1] <a href="http://lists.qt-project.org/pipermail/interest/2016-September/024387.html">
http://lists.qt-project.org/pipermail/interest/2016-September/024387.html</a><br>
-- <br>
Thiago Macieira - thiago.macieira (AT) intel.com<br>
  Software Architect - Intel Open Source Technology Center<br>
<br>
_______________________________________________<br>
Development mailing list<br>
Development@qt-project.org<br>
<a href="http://lists.qt-project.org/mailman/listinfo/development">http://lists.qt-project.org/mailman/listinfo/development</a><br>
</div>
</span></font>
</body>
</html>