Please help with writing spec for async JSON APIs

[Dean Landolt]

On Tue, Aug 4, 2015 at 9:53 AM, Mark Miller <erights at gmail.com> 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 <bjouhier at gmail.com> 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 <cabo at tzi.org>:
>>
>>> Hi Domenic,
>>>
>>> We have a spec for that: RFC 7464
>>>
>>
>
> --
>   Cheers,
>   --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150804/831ec8b7/attachment.html>