On Tue, Aug 4, 2015 at 9:53 AM, Mark Miller <[email protected]> wrote:
> +1 for line delimited JSON. It would be good to switch all users of > json-seq over to it and to deprecate json-seq. Perhaps an RFC would help. > > > On Mon, Aug 3, 2015 at 11:53 PM, Bruno Jouhier <[email protected]> wrote: > >> RFC 7464 has a different format (0x1E at beginning of every record) and a >> different media type (application/json-seq vs application/x-ldjson) than >> line delimited JSON (https://en.wikipedia.org/wiki/Line_Delimited_JSON). >> The 0x1E at the beginning of every record makes it hard to edit these >> files. >> >> Not sure it will improve interoperability, rather fragment things because >> it is likely that most people will stick to ldjson. >> >> 2015-08-04 1:29 GMT+02:00 Carsten Bormann <[email protected]>: >> >>> Hi Domenic, >>> >>> We have a spec for that: RFC 7464 >>> >> > > -- > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > FWIW there are very nice ways to encode stream-ready JSON such that its perfectly backward compatible with `JSON.parse` but still approximately as easy as line-delimited JSON. The whitespace within stringified JSON can be given optional significance, essentially it can act as a stream chunk delimiter hint. For example each element of a top level array on single line -- essentially equivalent to line-delimited JSON with 1 additional char per line, the comma. And its nearly as easy to parse -- it's only added complexity is the fact that as this is a valid profile of JSON, it'd be nice for parsers to validate syntax (really just trailing commas), but this is not strictly necessary. Top level arrays can be emitted as kv pairs per line, which allows for elegant streaming over associative array types. This is also really easy to parse and maintains backcompat w/ `JSON.parse`. It would also be possible to introduce optional nesting sigils using more whitespace, e.g. encoding chunk boundaries for two or more level nesting in a way that would allow parsers to allow opt-in SAXisms to any arbitrary level of nesting, but in a way that cleanly falls back to `JSON.parse`. As a side benefit, the layout of these nesting sigils could be designed in a way that makes it a lot easier to read than the extremely dense `JSON.stringify` default behavior. As it happens, using leading whitespace to indicate nesting would look a lot like pretty printing -- this wouldn't be anything more than a pretty printer with some optional embedded semantics attached. Async encode and decode behavior can be layered on top of the `depth: 1` serialization and deserialization. If you want more depth just add recursion. If at any point you don't want streaming, just use `JSON.parse`. I'm not sure something like this is strictly necessary in the language, but if it is, ISTM it would be pretty low-footprint way to get it in -- it'd be nice to avoid yet another format.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
