> So YAML makes a lot of sense. https://github.com/yaml/YAML2/wiki/People-Raging-About-YAML https://users.rust-lang.org/t/why-does-cargo-use-toml/3577/15
I would like to understand what all this discussion is about. What is the goal for Qt ? a) allow developers using Qt to have a simple, human-readable (that's the n°1 feature my users always asked about save and file formats) and easy to write serialization method ? b) compatibility with existing formats, e.g. I want to communicate with a webservice which speaks JSON or whatever c) maximum performance for e.g. message passing between two processes ? In any case, every time I ever used JSON it is because it was necessary for compatibility with existing interfaces - sometimes web APIs, sometimes human beings who are used to reading JSON. I don't see this going away any time soon... In any case, what would be the added value of Qt providing new serialization formats & APIs, especially wrt exisiting header-only libraries (rapidjson, nlohmann/json for instance in the json world) which provide better performance AND compliance than Qt's ? (again, for json, https://github.com/miloyip/nativejson-benchmark) Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Thu, Jun 14, 2018 at 3:13 PM, Thiago Macieira <[email protected]> wrote: > On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote: > > I’d leave XML out of this. It is difficult to integrate, as it has so > many > > special features (entities, CDATA and lot of other things) making it a > > rather complex specification. But there are a couple of other formats > that > > might fit a more generic data model. Yaml comes to my mind as an example, > > protobuf and flatbuffers might also be possible to stream into such a > > structure with some additional schema verification. > > YAML, like CBOR, was designed with compatibility in mind. In fact, it's > designed so JSON-YAML conversion is lossless in both directions. So YAML > makes > a lot of sense. > > I don't know much about PB and FB, but from what I've seen it's meant to > be a > serialisation format based on an IDL you describe. It's closer to > QDataStream > than to JSON. From what I've seen, it makes no sense to merge those with > the > other three than it does XML. > > > > I'm skeptical. What do you think?f > > > > One option could also be that we have a common implementation, and then a > > very thin API wrapper for each of the formats on top that will enforce > the > > format specific limitations and give you a fully typed API. > > That was my original plan. The QCborValue backend can be reused for JSON > as a > thin wrapper API. There's just a lot of copy & paste. > > -- > 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
