<div dir="ltr">It's true that the newline delimited feed is often "good enough". But it has a number of drawbacks:<div><ul><li>It is not JSON. This is especially annoying ¬†during development because most of the tools understand real JSON, not this format. For example during debugging you often work with small feeds (few entries but the entries can be long lines); it is very handy to be able to paste a whole feed into an editor and reformat it to visualize (or modify) the entries.<br></li><li>There is a special MIME type and a special file extension for them (see¬†<a href="https://en.wikipedia.org/wiki/Line_Delimited_JSON#MIME_type_and_file_extensions">https://en.wikipedia.org/wiki/Line_Delimited_JSON#MIME_type_and_file_extensions</a>) but I've never seen anyone use them (maybe I'm not curious enough). On the other hand I've often seen such feeds saved as `.json` files. So the level of interoperability is poor.<br></li><li>It does not let you cleanly associate header/trailer metadata with your feed. With true JSON, you can design your feed as `{ header: { ... }, body: [...], trailer: {...} }`. With ldjson you can still do it by formatting the header as a first line and the trailer (if any) as a trailer line but this is brittle (kinda of CSV in JSON, trailer forces you to test every entry).</li></ul><div>Note: I'm not screaming for an async/incremental parser API in core JS because I already have libraries to handle arbitrary large JSON feeds. But if such an API were standardized I'm sure I would get a more robust/optimized parser.</div><div><br></div><div>Bruno</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-03 22:22 GMT+02:00 Domenic Denicola <span dir="ltr"><<a href="mailto:d@domenic.me" target="_blank">d@domenic.me</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My understanding of most "streaming JSON" use in Node.js is that it actually is "newline-delimited JSON." That is, each line is parsed, delivered, and processed as a single chunk containing a JSON value, and the streaming nature comes from the incremental processing and backpressure as applied in between newline-delimited chunks.<br>
<br>
Part of the advantage of this is that it's extremely easy to specify and implement how it works.<br>
<br>
Bruno seems to indicate he's run in to use cases where it'd be useful to process a normal JSON object in a streaming fashion. That seems like a harder problem, indeed necessitating a SAX-like API.<br>
<div class="HOEnZb"><div class="h5"><br>
> -----Original Message-----<br>
> From: es-discuss [mailto:<a href="mailto:es-discuss-bounces@mozilla.org">es-discuss-bounces@mozilla.org</a>] On Behalf Of<br>
> Brendan Eich<br>
> Sent: Sunday, August 2, 2015 21:26<br>
> To: Bruno Jouhier<br>
> Cc: es-discuss<br>
> Subject: Re: Please help with writing spec for async JSON APIs<br>
><br>
> Exactly! Incremental and async, i.e., streaming.<br>
><br>
> XML quickly needed such APIs<br>
> (<a href="https://en.wikipedia.org/wiki/Simple_API_for_XML" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Simple_API_for_XML</a>,<br>
> <a href="https://en.wikipedia.org/wiki/StAX" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/StAX</a>). JSON's in the same boat.<br>
><br>
> /be<br>
><br>
> Bruno Jouhier wrote:<br>
> > A common use case is large JSON feeds: header + lots of entries +<br>
> > trailer<br>
> ><br>
> > When processing such feeds, you should not bring the whole JSON in<br>
> > memory all at once. Instead you should process the feed incrementally.<br>
> ><br>
> > So, IMO, an alternate API should not be just asynchronous, it should<br>
> > also be incremental.<br>
> ><br>
> > FWIW, I have implemented an incremental/evented parser for V8 with a<br>
> > simple API. This parser is incremental but not async (because V8<br>
> > imposes that materialization happen in the main JS thread). But, if<br>
> > the V8 restriction could be lifted, it could be made async with the<br>
> > same API. See <a href="https://github.com/bjouhier/i-json" rel="noreferrer" target="_blank">https://github.com/bjouhier/i-json</a><br>
> ><br>
> > i-json's API is a simple low level API. A more sophisticated solution<br>
> > would be a duplex stream.<br>
> ><br>
> > There was also a long discussion on this topic on node's GitHub:<br>
> > <a href="https://github.com/joyent/node/issues/7543" rel="noreferrer" target="_blank">https://github.com/joyent/node/issues/7543</a><br>
> ><br>
> > Bruno<br>
> > _______________________________________________<br>
> > es-discuss mailing list<br>
> > <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
> > <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
> _______________________________________________<br>
> es-discuss mailing list<br>
> <a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></div></blockquote></div><br></div>