News for hackers. Stuff that matters.
Re:Use streaming JSON to reduce latency on mobile by macspoofing on Monday February 19, 2018 @11:53AM (#16413958)
>I agree that a streaming response is cool, but why the dismissal of returning valid JSON, streamed?

JSON hasn't been designed for chunked interpretation. How would the client know when to start interpreting the received message? How could you tell the difference between a valid chunk or malformed response?

>With this new-line-delimited JSON format all your clients HAVE to know about your new protocol

Yes. It's probably not a good option for public. It should be a complement to a more general API. I would put this in the bucket of micro-optimization for very specific use-cases. Regardless, if you publish your API and document it, other developers should be able to consume it just fine. It's not rocket science.

Re:Use streaming JSON to reduce latency on mobile by beau on Monday February 19, 2018 @12:13PM (#16414105)
Re:Use streaming JSON to reduce latency on mobile by platz on Monday February 19, 2018 @02:21PM (#16415015)
> carriage-return (\r\n) delimited JSON-endocded activities

That's not JSON

Re:Use streaming JSON to reduce latency on mobile by Spivak on Tuesday February 20, 2018 @12:00AM (#16417955)
Why would you say that?

> Insignificant whitespace is allowed before or after any of the six structural characters.

Where whitespace may be space, carriage return, line feed, or horizontal tab. It's explicitly valid JSON.

https://tools.ietf.org/html/rfc7159#section-2

Re:Use streaming JSON to reduce latency on mobile by platz on Tuesday February 20, 2018 @12:07AM (#16417983)
ok - but my point is that it's a protocol, that is more specific than json i.e. streaming JSON in full generality has problems. if you want to restrict yourself to a subset and create a protocol, thats great - but it's not really "streaming JSON"
Re:Use streaming JSON to reduce latency on mobile by masklinn on Monday February 19, 2018 @01:49PM (#16414765)
> JSON hasn't been designed for chunked interpretation. How would the client know when to start interpreting the received message?

Neither has XML and yet we have plenty of working streaming XML parsers.

> How could you tell the difference between a valid chunk or malformed response?

Same as usual, when it breaks.