Il 25/09/2016 05:58, Thiago Macieira ha scritto: > > 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:
For the record, I'm for option 2, as I don't think it poses a huge burden (apart from an initial task to add older protocol versions to it, then it's just a matter of maintaining documentation, and we must do it anyhow). Plus, the mere existence of that page means that someone is relying on the binary format. That having being said, I agree that QDataStream hasn't got the best wire format or the best implementation, but this is totally orthogonal to the matter at hand. Cheers, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
