Please ignore my previous post as this is about the new line feed (ascii 12) and not "\n" (ascii 92 & 110).
On Thursday, July 4, 2013 6:04:59 PM UTC+2, Timothy J Fontaine wrote: > > 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] <javascript:> > > 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]<javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> 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] <javascript:>. >> 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.
