<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<br>
<div>
<div>On Sep 26, 2016, at 11:34, Simon Hausmann <<a href="mailto:Simon.Hausmann@qt.io">Simon.Hausmann@qt.io</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" style="font-size: 12pt; background-color: rgb(255, 255, 255); font-family: Calibri, Arial, Helvetica, sans-serif; position: static; z-index: auto;">
<div style="margin-top: 0px; margin-bottom: 0px;">Hi,</div>
<div style="margin-top: 0px; margin-bottom: 0px;"><br>
</div>
<div style="margin-top: 0px; margin-bottom: 0px;">I'm very much in favor of using a proper schema based system such as protocol buffers if we decide</div>
<div style="margin-top: 0px; margin-bottom: 0px;">to remove the black box from serialization. They don't appear to be connected, but the moment you</div>
<div style="margin-top: 0px; margin-bottom: 0px;">need to deal with changes in the format, the protobuf approach wins IMO. The other advantage is interoperability</div>
<div style="margin-top: 0px; margin-bottom: 0px;">with the world outside of Qt.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>There are many alternatives to protocol buffers, some of them faster and/or more compressed.  <a href="https://capnproto.org/">https://capnproto.org/</a> claims to be a really good one, for example.  It has an MIT license.  Zero-copy is a nice feature
 to have.  After what I read, Iíd probably never choose to use protocol buffers if it can be avoided.  You have to use the code generator, and itís not efficient.  But I never tried, either.</div>
<div><br>
</div>
<div>
<div>Being able to mmap the file and immediately treat it as the data structure that you really wanted is a nice feature to have; that kind of implementation is not necessarily the same thing as a serialization protocol, although the ideal serialization protocol
 could be designed so that you can deal with it either way.  Doesnít fit the QDataStream API, anyway.</div>
</div>
<div><br>
</div>
<div>Wikipedia has a comparison:  <a href="https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats">https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats</a></div>
<div><br>
</div>
<div>There are even several that claim to be both binary and human-readable.  i always thought that a binary format which doesnít require a schema, uses tags like XML, but can represent the common data types natively (various types of numbers, bools, enums,
 opaque byte arrays, and strings) and for which a tool is available to format it to be human-readable ought to be better than things like XML and JSON.  An early example is wbxml: WAP Binary XML (but it doesnít have any representation for floating-point numbers
 AFAICT).  I also wrote one which uses a string table for the tags, and binary representation for the tree structure and the data.  But then I realized maybe I should have designed it for mmapping rather than only for bytewise streaming.  But doing alignment
 wastes some space.</div>
<div><br>
</div>
<div>If you like schemas or IDL, thereís the DDS serialization protocol.  Weíve already tossed around the idea of having a Qt DDS wrapper because it would be useful in certain known industries.  But it requires more structure and discipline compared to tag-based
 formats.  It resembles CORBA because it comes from OMG.  Like CORBA, itís not worth the effort for rapid prototyping, only for larger-scale projects where the need for robustness outweighs the need to have a short development effort.</div>
<div><br>
</div>
<div>QDataStream is just a sequence - you have to know what to expect when you are deserializing, rather than checking tag names or using a schema.  Unless you just have a convention that the stream will consist of alternating tags and values.</div>
<div><br>
</div>
<div>Is it actually that useful?  Maybe we should deprecate it and come up with something better?</div>
<div><br>
</div>
</div>
</body>
</html>