> On Mar 17, 2016, at 3:12 AM, Jonas Sicking <jo...@sicking.cc> wrote: > >> On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr. <jackalm...@gmail.com> >> wrote: >> No, streams do not solve the problem of "how do you present a >> partially-downloaded JSON object". They handle chunked data *better*, >> so they'll improve "text" response handling, > > Also binary handling should be improved with streams. > >> but there's still the >> fundamental problem that an incomplete JSON or XML document can't, in >> general, be reasonably parsed into a result. Neither format is >> designed for streaming. > > Indeed. > >> (This is annoying - it would be nice to have a streaming-friendly JSON >> format. There are some XML variants that are streaming-friendly, but >> not "normal" XML.) > > For XML there is SAX. However I don't think XML sees enough usage > these days that it'd be worth adding native support for SAX to the > platform. Better rely on libraries to handle that use case. > > While JSON does see a lot of usage these days, I've not heard of much > usage of streaming JSON. But maybe others have? > > Something like SAX but for JSON would indeed be cool, but I'd rather > see it done as libraries to demonstrate demand before we add it to the > platform.
Something like SAX for JSON would be nice. For an immediately available userland solution RFC7049 is an alternative to JSON which is slightly more streaming friendly. Downside is that it's unreadable by humans, and a bit too low level for a fair amount of usecases. (Parsing is much simpler than existing binary object serialization formats, such as ASN1) Sangwhan [1] https://tools.ietf.org/html/rfc7049
