On 04/02/2011 08:18 AM, Cory Nelson wrote:

On Fri, Apr 1, 2011 at 5:29 PM, Rene Rivera<grafikrobot@gmail.com> wrote:

...

Students and other interested parties,

I would love it if there was a Boost quality JSON data parser, and optional printer, library. Currently I use one based on Spirit1 which has many drawbacks. I've been waiting for someone in the Spirit team, i.e. Joel, to have some mythical free time and inclination to write such a thing. But I'd really love one sooner, rather than later. Having one that is good and based on the latest Spirit would be wonderful.

I can't say I have the time to mentor such a project. Hence this is just a though ;-)

If someone does take this on, please be careful about using Spirit! It would be nice to be able to incrementally parse a large JSON document without having to buffer it all first, or have iterators that block to perform I/O, etc.

There are actually ways around all of these issues. michi7x7 posted on the Spirit mailing list in November 2010 a combination using asio and coroutines. michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

On 4/2/2011 6:34 PM, Gruenke, Matt wrote:

On Sat 4/2/2011 11:18 AM, Cory Nelson wrote:

...

It would be nice to be able to incrementally parse a large JSON document without having to buffer it all first, or have iterators that block to perform I/O, etc.

What about adding JSON support as part of Boost.Serialization?

That would be useless to me at the moment :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On 4/4/2011 1:15 AM, James Mansion wrote:

Rene Rivera wrote:

...

Students and other interested parties,

I would love it if there was a Boost quality JSON data parser, and optional printer, library. What about improving the one in PropertyTree?

Property Tree is not capable of faithfully representing the data that can be stored in a JSON file. For example: * One can't discern, as a user, between vectors/arrays and maps/objects. * It can't use key names with "." in the name. And one discrepancy which could be addressed: * It reinterprets some string data as non-string data (I'm referring to the strings "true" & "false" being interpreted as the values true & false). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On 4/5/2011 3:45 AM, Sebastian Redl wrote:

On 05.04.2011 07:11, Rene Rivera wrote:

...

* It can't use key names with "." in the name.

Yes it can. Though the parser might need to be audited to make sure it handles them correctly.

Really? Sorry if I'm not all that versed in what property tree can do.. But given this JSON: { "x" : { "transform.rotation" : 45, "transform.scale" : 1.5 } } How would one access the values "45" and 1.5 once it's read into a property tree? With the additional requirement that I need to know the full pair, i.e. that "transform.rotation" has a value of 45. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Hi, 2011/4/5 Rene Rivera <grafikrobot@gmail.com>

On 4/5/2011 3:45 AM, Sebastian Redl wrote:

...

On 05.04.2011 07:11, Rene Rivera wrote:

Property Tree is not capable of faithfully representing the data that

...

...

can be stored in a JSON file.

To be more precise, a ptree or wptree is not capable of doing this. A

...

basic_ptree instantiated with JSON-specific data and key types would be (though it would then be a superset of what JSON can do).

[...]

But wouldn't it be nice to have a generic JSON parser with an iterator based interface than can pull from a JSON data source; with a utility translator that can fill an std::map(or hash_map) and std::vector with key/values and values of boost::any(or equivalent) kind; that then property_tree could use be much nicer :-) Especially since it then would be possible for Boost Serialization to also use the same parser.

I made a GSoC proposal for a JSON library. More details can be viewed here: https://docs.google.com/document/pub?id=1qjEeIzfLstNIks4y6iGYmTn7cZSSsfIOULe... Comments are welcome! Regards, -- Murilo Adriano Vasconcelos http://murilo.wordpress.com