A random idea, haven't thought it through completely, would be to send
the response as a multipart message where each part is a valid JSON
object. Should be able to stream the MIME parsing and then hand each
chunk off to a JSON stream parser.

-- Daniel R. <[email protected]> [http://danielr.neophi.com/]


On Thu, May 24, 2012 at 3:14 AM, Bruno Jouhier <[email protected]> wrote:
> You could make it JSON compliant by emitting a [ line at the beginning of
> the stream and a false] line at the end (and adding a comma at the end of
> each line).
> The extra value at the end could be interpreted as a "more" indicator. If
> true it means that this is only a stream fragment and that another fragment
> is expected later. If false it means that the stream is really over.
>
> With this you could use a content-type like "application/json;
> layout=line-stream".
>
> The only thing that would need to be standardized then would be the layout
> parameter and its values.
>
>
> 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 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

-- 
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

Reply via email to