+1 to this.  I'm a bit horrified to see that newlines are being 
incorporated into a JSON-like standard as a record separator when newlines 
are in fact supported within JSON bodies.

IMO a generically named standard like "*application/x-json-stream" should 
be a strict subset of JSON with the following requirements:*

1. The top-level entity MUST be an array
2. A json-stream parser SHOULD emit "data" when each entity of a TLE is 
fully parsed.
3. A json-stream parser SHOULD emit "end" when the last entity of the TLE 
has been parsed.

I feel like this would address the concerns with framing and streaming 
applications without fundamentally breaking JSON.

That said, it would be a whole lot easier to integrate with Line-separated 
JSON in shell scripts, and perhaps this begs an explicit 
"application/x-line-separated-json" standard which is a superset of a 
NL-JSON standard wherein newlines are not permitted (a superset of a 
subset, as ridiculous as that sounds).

On Friday, July 5, 2013 11:16:09 AM UTC-4, Floby wrote:
>
> Gave a go at a parser for an actual array at 
> https://github.com/Floby/node-dummy-streaming-array-parser
> using some regex based tokenizer.
>
> still more complicated than input.pipe(split()).pipe(through(JSON.parse))
>
> On Wednesday, 23 May 2012 22:47:36 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 
>> <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/
New group rules: 
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/nodejs/e943a298-4da1-4cf4-a963-fa4d20ad66f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to