search

discomarathon / google-gson

Automatically exported from code.google.com/p/google-gson
0 stars 0 forks source link

Should support SAX like function? #28

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Sometime, I need parse huge json input or I need customize the pasre
process. Having SAX stream API is going to be very helpful.

Original issue reported on code.google.com by jiming...@gmail.com on 4 Aug 2008 at 3:01

GoogleCodeExporter commented 9 years ago 
Would this be served by providing a hook to plug-in a different JSON parser? 

Can you give us some concrete examples of where this will be useful? You can use
custom serializer/deserializers to do the customized handling anyway. But you 
are
right, our parser creates the parse tree first, so can choke on very large 
input.

Original comment by inder123 on 4 Aug 2008 at 6:44

GoogleCodeExporter commented 9 years ago 
http://www.cowtowncoder.com/hatchery/jackson/index.html

I am using JSON-lib and looking for a better one. I myself like upper lib so far
since it supply a Streaming API which allows to process huge data. But then I 
found
your lib, which is also a nice one expect do not support Streaming API. I think 
which
would be a highlight if you can add it in.

When I said customize the parsing, I mean you could supply event like SAX do, 
so I
can create new instance or set value according to the events. 

I do not how to do these because I do not know parsing algorithm. But I wish to
supply some idea to make gson better.

Thanks,

Jiming

Original comment by jiming...@gmail.com on 5 Aug 2008 at 3:09

GoogleCodeExporter commented 9 years ago 
We thought more about it, and it seems that this is worth doing since it will 
enable
Gson to process really large documents. We will essentially have to rewrite our
parser to either support SAX (event based) or StAX (Streaming based) parsing. 
This
can probably be done by modifying our JavaCC grammar itself. This is a major
undertaking, but we will consider this for one of our major releases.

Original comment by inder123 on 5 Aug 2008 at 6:12

GoogleCodeExporter commented 9 years ago 
Great to hear that!

Thanks and looking forward to that.

Jiming

Original comment by jiming...@gmail.com on 6 Aug 2008 at 2:19

GoogleCodeExporter commented 9 years ago 
Just a suggestion: make it "pull" variety (~= stax), since it is trivial to 
invert
Stax to produce SAX-like events (so "SAX" part can build on lower-level "Stax" 
part).
The reverse is not generally possible without multi-threading (or language 
support
for co-procedures/closures).

Original comment by tsaloranta@gmail.com on 11 Aug 2008 at 10:30

GoogleCodeExporter commented 9 years ago 
Hi I just ran into this issue as well.  Any timeline for when issue 28 will be 
addressed?

Original comment by toddwe...@gmail.com on 21 Nov 2008 at 4:56

GoogleCodeExporter commented 9 years ago 
Well, I looked into rewriting our JavaCC parser to be a SAX or pull-based one, 
and 
was not terribly successful. At this time, we have put this on hold. If someone 
can 
point us to a third-party SAX/pull parser that we can adapt, we will consider 
using 
it. Or better, help us write one. 

This will likely have an impact on the backward compatibility. However, that is 
something we can carefully weigh on.

Original comment by inder123 on 22 Nov 2008 at 2:15

GoogleCodeExporter commented 9 years ago 
We dont have SAX like functions, but Gson 1.4 adds a JsonParserAsync class that 
lets 
you parse multiple JSON objects on a stream. 

Overall, backwards compatibility is quite important for us, so I dont see us 
breaking 
that in favor of a SAX like parser (which is in general harder to use).

Original comment by inder123 on 1 Oct 2009 at 4:01