It's about framing. Consider a persistent connection without a known total content delivery, or a streaming interface. If you send it framed as an array you won't be able to process the information as it arrives as you'll always be waiting for the end.
An environment like application/x-json-stream lets you continue to receive information and process it as it is available, without necessarily needing to use another abstraction like a websocket, which may or may not be available for your use. On Thu, Jul 4, 2013 at 8:54 AM, Simon Majou <[email protected]> wrote: > I don't get the interest of this thing. > > If you want to send an array, just use an array. > > If you want to delimit json messages on a stream without parsing the > messages, I don't know if it is practical as JSON accepts any unicode. > > \n is valid inside of strings (http://json.org/string.gif). > > > On Wednesday, May 23, 2012 10:47:36 PM UTC+2, Ken wrote: >> >> *There seem to be a growing number of tools & packages around that >> implement some form of JSON streaming where multiple standard JSON objects >> are delimited by extra newlines, e.g. >> >> * >> *{ "id": 1, "foo": "bar" }* >> *{ "id": 2, "foo": "baz" }* >> *...* >> ** >> * >> This format seems both pragmatic and useful, but is not JSON compliant >> (i.e. doesn't parse with a standard JSON parser), so it seems inappropriate >> to serve up as "application/json". >> Request-JSONStream<https://github.com/smurthas/Request-JSONStream>uses >> "application/jsonstream", Google searching shows at least one use of >> "application/x-json-stream", and there are a number of services that use >> "application/json" and expect clients to just deal with it (cf. >> https://github.com/senchalabs/connect/issues/538). >> >> Since I'm about to make heavy use of this technique in a way that will be >> a little difficult to unwind later I'd like if at all possible get on board >> with whatever will become the standard (defacto or official). Anyone aware >> of any efforts underway to standardize this, or packages/services that have >> enough momentum to drive a standard in the future? >> >> * > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
