Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should support SAX like function? #28

Closed
GoogleCodeExporter opened this issue Mar 19, 2015 · 8 comments
Closed

Should support SAX like function? #28

GoogleCodeExporter opened this issue Mar 19, 2015 · 8 comments

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Changed state: Accepted
  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Changed state: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant