On Tuesday 27. September 2011 23.04.55 ext Girish Ramakrishnan wrote: > Hi, > > On Tue, Sep 27, 2011 at 11:52 PM, Mark <[email protected]> wrote: > > On Tuesday, September 27, 2011, Thiago Macieira <[email protected]> wrote: > >> On Tuesday, 27 de September de 2011 06:20:17 Girish Ramakrishnan wrote: > >>> Hi, > >>> > >>> On Tue, Sep 27, 2011 at 1:40 AM, Thiago Macieira <[email protected]> wrote: > >>> > JSON support is provided by many different implementations already. I > >>> > don't > >>> > think we can choose one right now. So we should simply list all the > >>> > available ones and apply the Darwin principle: standardise on the one > >>> > that survives. > >>> > >>> Here's one I wrote based on QLALR and it's way faster than the (very > >>> popular) qjson (benchmarks are in the repo): > >>> http://gitorious.org/qjsonparser/qjsonparser. > >>> > >>> Does V8 have it's own json parser that we can use? > >> > >> That's why I said we have 5 different JSON parsers today and Darwin > >> should determine which one we'll pick. > > > > About V8, Qt is gonna use that right? I'm guessing V8 has it's own uber > > fast json parser so why not make a qt layer for that..? Seems like that > > gives no duplication and json in c++, everyone happy :) > > AFAICT, v8's json parser is written in JavaScript. I don't think it's > a problem that it's not in C++, though. What I do think is a problem > is that apps now need to have v8 just to use JSON (maybe this is an > imaginary problem). > > If I understood Thiago, he would prefer to 'wait and see which one > survives'. I would instead like us to choose one and provide an api > for JSON in qtbase, asap. Pretty much every project I work with needs > JSON these days. JSON implementation is quite trivial anyway (like > ~200-300 lines max), so I don't see the need to have competing > implementations 'fight it out'. > > Does anyone have a strong opinion on what API we should have for a > JSON parser in Qt? I quite like the qjson approach of just providing a > QVariant. QVariant conversion has a performance overhead but it's very > easy to work with and from what I have seen the big performance impact > is in the parsing phase and not when getting data out of the QVariant. > The alternate is a stream based API like the XML one but I think this > is just too cumbersome. > > Girish > _______________________________________________ > Qt5-feedback mailing list > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Hi, As Thiago already pointed out, we have few (too many) competing implementation of JSON parsers, and two different environments (C++ and JS/QML) in which they should work. We should have only one implementation mainly because we can't allow behavior differences and because of general maintenance costs (testing, performance improvements, etc.). Currently, I do not see obvious winner. For QML, V8 implementation may be preferred, as it creates a native JS object, which can be used directly from a QML application. On other hand from C++ point of view it would be an overkill to start full JS environment to parse a tiny json file. But of course everyone will use QML, so it is not a problem, right :-)? What I do not like about qjsonparser mentioned by Girish, is that it uses QVariant as a type for object storage. It won't be fast, ever. QVariant is a type safe replacement for void*, and nothing more. I think it is misuse to treat it as a correct object representation. In Qt, we already have two classes, which takes that responsibilities; QObject and QJSValue. The first should be known to everyone, second represents a JS object. Another issue related to QVariant is that it always needs to be converted to something, in a common case you need to iterate over QVariantMap to create an useful representation. I think we need more benchmarks, before we can make the right decision. Cheers, Jędrek ps. JSON means JavaScript Object Notation, so JS and other dynamic languages will take most of it, for C++ it will be always a bit artificial.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
