[Development] RFC: unified data model API in QtCore

[Jean-Michaël Celerier]

> 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 <thiago.macieira at intel.com>
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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180614/3095b685/attachment.html>