Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Edward Welbourne]

> On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote:
>>> Cons:
>>> Suppresses move construction as in
>>>QCborValue v = array[n];
>>> this still compiles, but passes through the copy constructor, not
>>> the move one. We cana add an extra move constructor for const
>>> QCborValue && if necessary.

On 6 Oct 2018, at 00:47, Thiago Macieira  wrote:
>> Never mind, you can't move from the const rvalue reference. It needs
>> to be modifiable.
>>
>> So, again: should we have the const in the return types at the
>> expense of losing the move semantic?

Lars Knoll (7 October 2018 10:53)
> I’d go for returning a const object. It’s a shame to loose the move
> semantics, but the other case would lead to easy programming errors.

The change currently staged for integration [0] only adds const to the
QCborValue return types of the read-only operator[] on QCbor{Array,Map};
as noted in the review comments there, there are several other methods
returning QCborValue, e.g. at(index) and value(key), that potentially
need to also return it as const.  My rationale for limiting this to
operator[] was that a['b']['c']['d'] = 12 might seem like a reasonable
thing to do, while a.at('b')['c']['d'] = 12 seems more obviously like a
senseless thing to attempt.

[0] https://codereview.qt-project.org/240046

So the question arises: which other QCbor{Map,Array} methods should
const-qualify their QCborValue returns ?

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Lars Knoll]

> On 6 Oct 2018, at 00:47, Thiago Macieira  wrote:
> 
> On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote:
>> Cons:
>> Suppresses move construction as in
>>QCborValue v = array[n];
>> this still compiles, but passes through the copy constructor, not the move
>> one. We cana add an extra move constructor for const QCborValue && if
>> necessary.
> 
> Never mind, you can't move from the const rvalue reference. It needs to be 
> modifiable.
> 
> So, again: should we have the const in the return types at the expense of 
> losing the move semantic?

I’d go for returning a const object. It’s a shame to loose the move semantics, 
but the other case would lead to easy programming errors.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Thiago Macieira]

On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote:
> Cons:
>  Suppresses move construction as in
> QCborValue v = array[n];
> this still compiles, but passes through the copy constructor, not the move
> one. We cana add an extra move constructor for const QCborValue && if
> necessary.

Never mind, you can't move from the const rvalue reference. It needs to be 
modifiable.

So, again: should we have the const in the return types at the expense of 
losing the move semantic?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Edward Welbourne]

Thiago Macieira (5 October 2018 17:35) asked me:
> Eddy: what happens in the new API if you write:
>   const QCborArray array = { QCborArray{ 1 } };
>   QCborValue v = array[0];
>   v[0] = 2;
>
> Does that modify array?

No.  It should only modify what v[0] reports, or a v.toArray()[0]
reports, after the assignment.  My addition to the end of
tst_QCborValue::arrayDefaultInitialization() verifies exactly this with
the QVERIFY(a2.isEmpty()); that it adds, after such an assignment.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Thiago Macieira]

On Friday, 5 October 2018 04:25:05 PDT Edward Welbourne wrote:
> dev (5.13):
> QCborValue{Ref,}::operator[] added where missing
> https://codereview.qt-project.org/240042
>
> The first's const-ing and the second's padding are needed in 5.12 to let
> the last be backwards-compatible, when it lands.  Once the first two land,
> we can finally close the qtbase API review.

May as well bring this question to the list as a whole now:

QCborValue, Array and Map have methods like:

const QCborValue operator[](qint64 index) const;

We're trying to figure out if the returned type should be const.

Pros:
 1) once QCborValue can be modified by the APi above, you can't accidentally 
use it in a const object
 2) you can't write
   array[n] = newValue;

Cons:
 Suppresses move construction as in
QCborValue v = array[n];
this still compiles, but passes through the copy constructor, not the move 
one. We cana add an extra move constructor for const QCborValue && if 
necessary.

Eddy: what happens in the new API if you write:
  const QCborArray array = { QCborArray{ 1 } };
  QCborValue v = array[0];
  v[0] = 2;

Does that modify array?


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Edward Welbourne]

On Sunday, 9 September 2018 04:16:24 PDT Tor Arne Vestbø wrote:
>> This is exactly the kind of stuff I brought up at the contributors
>> summit.  We should strive to at least be on par with QJson, but I’m
>> hoping we can also have a nice API for writing (something QJson
>> doesn’t easily facilitate). Any chance the read-only stuff can be
>> added at least Thiago?

Thiago Macieira (9 September 2018 18:36) wrote:
> It can be, but we're already past feature freeze and I don't have time
> to do it right now. I'm completely swamped at work and I'm dedicating
> any free minutes I have for Qt to do code reviews for others.
>
> The issue with map["hello"] can be an API review issue, though.

For the sake of openness (we took most of this discussion off-line), the
end result of that was:

5.12:
QCbor{Map,Array}::operator[] grow over-loads for string literals and all
read-only variants return const QCborValue:
https://codereview.qt-project.org/240046

QCborArray::operator[] and insert() allow indices past the end of the
array, padding the array with invalid entries:
https://codereview.qt-project.org/240537

dev (5.13):
QCborValue{Ref,}::operator[] added where missing
https://codereview.qt-project.org/240042

The first's const-ing and the second's padding are needed in 5.12 to let
the last be backwards-compatible, when it lands.  Once the first two land,
we can finally close the qtbase API review.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Thiago Macieira]

On Sunday, 9 September 2018 04:16:24 PDT Tor Arne Vestbø wrote:
> This is exactly the kind of stuff I brought up at the contributors summit.
> We should strive to at least be on par with QJson, but I’m hoping we can
> also have a nice API for writing (something QJson doesn’t easily
> facilitate). Any chance the read-only stuff can be added at least Thiago?

It can be, but we're already past feature freeze and I don't have time to do 
it right now. I'm completely swamped at work and I'm dedicating any free 
minutes I have for Qt to do code reviews for others.

The issue with map["hello"] can be an API review issue, though.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Thiago Macieira]

On Sunday, 9 September 2018 03:25:54 PDT Sze Howe Koh wrote:
> Hi Thiago,
> > Any chance you can give it a go? Or someone else?
> 
> I've installed the Qt 5.12 alpha for MSVC 2015 and started playing
> with the CBOR API.
> 
> map["hello"] = foo; // ERROR C2593: Operator '[' is ambiguous

That's what you get for trying to make a modern API that uses QLatin1String 
and QStringView... But then I changed to QString.

> map[QString("hello")] = foo; // OK
> 
> The ambiguity disappears if I remove either operator[](const QString&)
> OR operator[](const QCborValue&). Oddly, operator[](QLatin1String)
> doesn't matter. Why's that?

Needs investigation. I had QStringView originally, but had to change for some 
reason.

> Also, chained operator[] currently doesn't work because
> QCborValueRef::operator[](...) doesn't exist:
> 
> qDebug() << array[1]; // OK
> qDebug() << array[1][2]; // ERROR C2676: 'QCborValueRef' does not
> define this operator or a conversion to a type acceptable to the
> predefined operator

That's what I said in the previous email. When I asked for someone to "give it 
a go", I meant adding the necessary API to make it work.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Tor Arne Vestbø]

> On 9 Sep 2018, at 12:25, Sze Howe Koh  wrote:
> 
> Hi Thiago,
> 
> On Sat, 18 Aug 2018 at 01:51, Thiago Macieira  
> wrote:
>> 
>> On Friday, 17 August 2018 08:13:21 PDT Tor Arne Vestbø wrote:
 Now, looking at the code, I don't think it does work. I thought that
 QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a
 set of non-const overloads returning QCborValueRef might be the trick.
>>> That would be great to have as part of the API yes
>> 
>> I won't have time to experiment with it before feature freeze. Technically,
>> the API freeze doesn't happen until Beta, so we have a few more weeks, but I
>> wouldn't hold my hopes up that I will have time to trial this.
>> 
>> Any chance you can give it a go? Or someone else?
> 
> I've installed the Qt 5.12 alpha for MSVC 2015 and started playing
> with the CBOR API.
> 
>map["hello"] = foo; // ERROR C2593: Operator '[' is ambiguous
>map[QString("hello")] = foo; // OK
> 
> The ambiguity disappears if I remove either operator[](const QString&)
> OR operator[](const QCborValue&). Oddly, operator[](QLatin1String)
> doesn't matter. Why's that?
> 
> Also, chained operator[] currently doesn't work because
> QCborValueRef::operator[](...) doesn't exist:
> 
>qDebug() << array[1]; // OK
>qDebug() << array[1][2]; // ERROR C2676: 'QCborValueRef' does not
> define this operator or a conversion to a type acceptable to the
> predefined operator

This is exactly the kind of stuff I brought up at the contributors summit. We 
should strive to at least be on par with QJson, but I’m hoping we can also have 
a nice API for writing (something QJson doesn’t easily facilitate). Any chance 
the read-only stuff can be added at least Thiago?

Tor Arne 


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Sze Howe Koh]

Hi Thiago,

On Sat, 18 Aug 2018 at 01:51, Thiago Macieira  wrote:
>
> On Friday, 17 August 2018 08:13:21 PDT Tor Arne Vestbø wrote:
> > > Now, looking at the code, I don't think it does work. I thought that
> > > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a
> > > set of non-const overloads returning QCborValueRef might be the trick.
> > That would be great to have as part of the API yes
>
> I won't have time to experiment with it before feature freeze. Technically,
> the API freeze doesn't happen until Beta, so we have a few more weeks, but I
> wouldn't hold my hopes up that I will have time to trial this.
>
> Any chance you can give it a go? Or someone else?

I've installed the Qt 5.12 alpha for MSVC 2015 and started playing
with the CBOR API.

map["hello"] = foo; // ERROR C2593: Operator '[' is ambiguous
map[QString("hello")] = foo; // OK

The ambiguity disappears if I remove either operator[](const QString&)
OR operator[](const QCborValue&). Oddly, operator[](QLatin1String)
doesn't matter. Why's that?

Also, chained operator[] currently doesn't work because
QCborValueRef::operator[](...) doesn't exist:

qDebug() << array[1]; // OK
qDebug() << array[1][2]; // ERROR C2676: 'QCborValueRef' does not
define this operator or a conversion to a type acceptable to the
predefined operator


Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Mikhail Svetkin]

Yes, this library is very cool and requires only c++11.

Best regards,
Mikhail


On Wed, 22 Aug 2018 at 16:47, Tor Arne Vestbø  wrote:

> On 17 Aug 2018, at 17:08, Thiago Macieira 
> wrote:
> >
> > On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote:
> >>> Unless someone can volunteer to test. I *think* my design is slightly
> >>> better than QJsonValue, so the following should work:
> >>>
> >>> value[1]["hello"][32] = false;
> >>
> >> That’s great news. I assume it’s also easy to convert from and to JSON,
> so
> >> that one could use QCbor as an intermediate data format if one needs to
> >> modify JSON In place and write it out again?
> >
> > Please note I said that I *think* it should work, not that it does work.
> Could
> > you give it a try and see if it makes your life easier?
> >
> > Now, looking at the code, I don't think it does work. I thought that
> > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a
> set
> > of non-const overloads returning QCborValueRef might be the trick. And
> it's a
> > trick we can add to QJsonValue too.
> >
> > Converting from JSON is lossless and converting that content back to
> JSON is
> > lossless too. It's just not particularly efficient today.
>
> This library looks really nice:
>
> https://cocoapods.org/pods/nlohmann_json
>
> Tor Arne
>
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >  Software Architect - Intel Open Source Technology Center
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Tor Arne Vestbø]

On 17 Aug 2018, at 17:08, Thiago Macieira  wrote:
> 
> On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote:
>>> Unless someone can volunteer to test. I *think* my design is slightly
>>> better than QJsonValue, so the following should work:
>>> 
>>> value[1]["hello"][32] = false;
>> 
>> That’s great news. I assume it’s also easy to convert from and to JSON, so
>> that one could use QCbor as an intermediate data format if one needs to
>> modify JSON In place and write it out again?
> 
> Please note I said that I *think* it should work, not that it does work. 
> Could 
> you give it a try and see if it makes your life easier?
> 
> Now, looking at the code, I don't think it does work. I thought that 
> QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a set 
> of non-const overloads returning QCborValueRef might be the trick. And it's a 
> trick we can add to QJsonValue too.
> 
> Converting from JSON is lossless and converting that content back to JSON is 
> lossless too. It's just not particularly efficient today.

This library looks really nice:

https://cocoapods.org/pods/nlohmann_json

Tor Arne 

> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Arnaud Clère]

Hi,

Unfortunately I do not think I can help with the QCborValue development and 
Json/Cbor refactoring. 
Just, from my experience, Json and Cbor share so much that the refactoring 
makes a lot of sense and having an efficient, editable, in-memory 
representation of the underlying data is a nice goal for many use cases (was 
not it the idea of a "JsonDb"?).

Now, regarding the "structured traces" use case, converting the user-defined 
data types (and Qt types) to such representation at the tracepoint would only 
make sense performance-wise if the in-memory representation:
- require one or very few heap allocations per tracepoint
- can be copied to the log as a single chunk
Does the new design would allow that?

Even in this case, it would probably be better performance-wise to use the kind 
of thin-wrapper "QBind" API that I am pushing since we managed to implement it 
without heap allocation and with only 20% CPU overhead compared to hand-written 
serialisation (be it QDebug or QDataStream, etc.).

Finally, as a user, I can cope with reasonable API changes but new features 
suck if they do not work, so I would probably stay away from the "torpedoes" 
unless I am sure they are targeting the right thing 😊

Cheers,
Arnaud

-Original Message-
From: Thiago Macieira  
Sent: jeudi 16 août 2018 22:11
To: development@qt-project.org
Subject: Re: [Development] unified data model API in QtCore => thin wrapper 
proposal

On Wednesday, 20 June 2018 06:05:35 PDT Arnaud Clère wrote:
> Hi,
> Thiago, did you decide on something regarding QCborValue in Qt5.12?

Hello Arnaud, all

No, I have not. I have not had the time to read your email yet and nor have I 
had time to even test if the API I designed does what we discussed in Oslo.

I will not have time to do any of that before the 5.12 feature freeze.

So we need a summary decision:
 a) yank it out
 b) leave it as is and damn the torpedoes

Unless someone can volunteer to test. I *think* my design is slightly better 
than QJsonValue, so the following should work:

value[1]["hello"][32] = false;

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Thiago Macieira]

On Friday, 17 August 2018 08:13:21 PDT Tor Arne Vestbø wrote:
> > Now, looking at the code, I don't think it does work. I thought that
> > QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a
> > set of non-const overloads returning QCborValueRef might be the trick.
> That would be great to have as part of the API yes

I won't have time to experiment with it before feature freeze. Technically, 
the API freeze doesn't happen until Beta, so we have a few more weeks, but I 
wouldn't hold my hopes up that I will have time to trial this.

Any chance you can give it a go? Or someone else?

> > And it's a trick we can add to QJsonValue too.
> 
> That would be great, but I think it was kind of tricky with the current
> design of QJsonValue.

Fair enough. My long-term goal is to replace the QJsonDocument internals with 
QCborContainerPrivate. That way, the conversion from JSON to CBOR is O(1) and 
the conversion backwards is just a validation.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Tor Arne Vestbø]

> On 17 Aug 2018, at 17:08, Thiago Macieira  wrote:
> 
> On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote:
>>> Unless someone can volunteer to test. I *think* my design is slightly
>>> better than QJsonValue, so the following should work:
>>> 
>>> value[1]["hello"][32] = false;
>> 
>> That’s great news. I assume it’s also easy to convert from and to JSON, so
>> that one could use QCbor as an intermediate data format if one needs to
>> modify JSON In place and write it out again?
> 
> Please note I said that I *think* it should work, not that it does work. 
> Could 
> you give it a try and see if it makes your life easier?
> 
> Now, looking at the code, I don't think it does work. I thought that 
> QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a set 
> of non-const overloads returning QCborValueRef might be the trick.

That would be great to have as part of the API yes

> And it's a trick we can add to QJsonValue too.

That would be great, but I think it was kind of tricky with the current design 
of QJsonValue.

Tor Arne 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Thiago Macieira]

On Friday, 17 August 2018 02:50:32 PDT Tor Arne Vestbø wrote:
> > Unless someone can volunteer to test. I *think* my design is slightly
> > better than QJsonValue, so the following should work:
> > 
> > value[1]["hello"][32] = false;
> 
> That’s great news. I assume it’s also easy to convert from and to JSON, so
> that one could use QCbor as an intermediate data format if one needs to
> modify JSON In place and write it out again?

Please note I said that I *think* it should work, not that it does work. Could 
you give it a try and see if it makes your life easier?

Now, looking at the code, I don't think it does work. I thought that 
QCborValue::operator[] returned QCborValueRefs, but it doesn't. Adding a set 
of non-const overloads returning QCborValueRef might be the trick. And it's a 
trick we can add to QJsonValue too.

Converting from JSON is lossless and converting that content back to JSON is 
lossless too. It's just not particularly efficient today.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Tor Arne Vestbø]

> On 16 Aug 2018, at 22:11, Thiago Macieira  wrote:
> 
> On Wednesday, 20 June 2018 06:05:35 PDT Arnaud Clère wrote:
>> Hi,
>> Thiago, did you decide on something regarding QCborValue in Qt5.12?
> 
> Hello Arnaud, all
> 
> No, I have not. I have not had the time to read your email yet and nor have I 
> had time to even test if the API I designed does what we discussed in Oslo.
> 
> I will not have time to do any of that before the 5.12 feature freeze.
> 
> So we need a summary decision:
> a) yank it out
> b) leave it as is and damn the torpedoes
> 
> Unless someone can volunteer to test. I *think* my design is slightly better 
> than QJsonValue, so the following should work:
> 
>   value[1]["hello"][32] = false;

That’s great news. I assume it’s also easy to convert from and to JSON, so that 
one could use QCbor as an intermediate data format if one needs to modify JSON 
In place and write it out again?

Tor Arne 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Thiago Macieira]

On Wednesday, 20 June 2018 06:05:35 PDT Arnaud Clère wrote:
> Hi,
> Thiago, did you decide on something regarding QCborValue in Qt5.12?

Hello Arnaud, all

No, I have not. I have not had the time to read your email yet and nor have I 
had time to even test if the API I designed does what we discussed in Oslo.

I will not have time to do any of that before the 5.12 feature freeze.

So we need a summary decision:
 a) yank it out
 b) leave it as is and damn the torpedoes

Unless someone can volunteer to test. I *think* my design is slightly better 
than QJsonValue, so the following should work:

value[1]["hello"][32] = false;

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] unified data model API in QtCore => thin wrapper proposal

[Arnaud Clère]

Hi,
Thiago, did you decide on something regarding QCborValue in Qt5.12?

For structured traces, we have to deal with any user-defined data types so, we 
can do with QCborValue, QJsonValue or QFoo too. Now, the value of exposing the 
common backend of QJson and QCbor as a QFoo binary format is not clear to me, 
and the "lowest common denominator" approach is inherently limited.

In my latest QBind prototype, we can write any user-defined type in various 
formats, and we can even take a copy of the user-defined type to serialize it 
later. So, QFoo is not required as an intermediate storage and would probably 
be slower. The latest benchmark shows the QBind approach can be *very* 
efficient:

(usecs)  |QDebug|Json|Cbor|Writable|Writable>Cbor
MSVC 17
 This email is to start that discussion and answer these questions:
>   a) should we have this API?
>   b) if so, what would this API look like?
>   c) if not, should we unify at least JSON and CBOR?
>   c) either way, should remove QCborValue until we have it?
...
> This API would also be the replacement of the JSON and CBOR parsers, 
> for which we'd have a unified API, something like:
>   QFoo json = QJson::fromJson(jcontent);
>   QFoo cbor = QCbor::fromCbor(ccontent);
>   qDebug() << QCbor::toDiagnosticFormat(json);// yes, json

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development