RFC 7464 support?

[nicowilliams]

RFC 7464 defines a "JSON text sequence" MIME type that consists of a sequence (naturally) of JSON texts where each text starts with an ASCII RS (record separator, 0x1E) and ends with an ASCII LF (newline, 0x0A). There is no requirement that the JSON texts be "compact" (no interstitial newlines) but generally that would be the case, and we could always add a new MIME type that is like this but with compactness required.

Compare to the commonly used compact JSON text sequences with newlines after each JSON text (as emitted by jq -c, and also various HTTP JSON APIs).

Might the use of unambiguous record separators make it easier to parse incrementally with SIMD?

See also #188.

[lemire]

We support ndjson and jsonlines.

Supporting the format you describe would indeed be easier. So adding support is not difficult.

Is it in actual use?

[nicowilliams]

We support ndjson and jsonlines.

That was originally my intent for RFC 7464, but the WG had other ideas and we ended up with this. It's... kinda good, but also odd enough that adoption is low.

Supporting the format you describe would indeed be easier. So adding support is not difficult.

I figured as much!

Is it in actual use?

jq implements it. A search for rfc 7464 implementation finds a few other implementations (and more I'm not listing here).

But is it actually used in any products or open source or Internet protocols? Not to my knowledge, though why would I get told. I have used it at $WORK, but I wouldn't count that.

It's possible that if simdjson were faster / more reliable using JSON text sequences than ndjson/jsonlines then there might be more use of JSON text sequences. But don't go out of your way based on that :)

https://simdjson.org/api/0.4.0/md_doc_parse_many.html does refer to RFC 7464:

[lemire]

It would make sense to support it, at least so that inputs are supported.