On Wed, May 23, 2012 at 3:00 PM, Mark Hahn m...@hahnca.com wrote:
it seems that the work on the client side to do streaming parsing gets
much harder
I don't understand? Parsing commas is hard? However you planned on parsing
newlines could parse commas instead.
It goes from trivial
application/x-json-stream - JSON messages (without extra whitespace)
newline separated.
Several streaming json parsers support this already out of the box. They
ignore the newlines and know when a json body ends because of the parser
state. People who don't have a streaming parser, can search
Several streaming json parsers support this already out of the box.
They ignore the newlines and know when a json body ends because of the
parser state.
Pretty much sums it up :)
Nuno
On Thu, May 24, 2012 at 6:05 PM, Tim Caswell t...@creationix.com wrote:
application/x-json-stream - JSON
On Thu, May 24, 2012 at 12:05:13PM -0500, Tim Caswell wrote:
On Thu, May 24, 2012 at 11:52 AM, Isaac Schlueter i...@izs.me wrote:
On Wed, May 23, 2012 at 3:00 PM, Mark Hahn m...@hahnca.com wrote:
it seems that the work on the client side to do streaming parsing gets
much harder
I
Using arbitrary x- subtypes is allowed but if this format ever leaves
experimental status we'd want to drop the x- and I don't think
application/json-stream is ideal, in particular because the only other
current use of the word stream in content types is
application/octet-streamwhich has no
*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
Stay with the standard. Crockford has made it clear that the standard will
never change. It is one of json's strengths. You can count on the fact
that what you do now will work forever.
On Wed, May 23, 2012 at 1:47 PM, Ken ken.woodr...@gmail.com wrote:
*There seem to be a growing number of
Newline-delimited JSON is pretty common. I don't think there's a
standard content-type for it though.
Stay with the standard.
Well, this *is* the standard, just combined with newline-delimited streaming.
--Josh
On Wed, May 23, 2012 at 2:05 PM, Mark Hahn m...@hahnca.com wrote:
Stay with the
I've actually seen a few people use custom content types for it but not defacto
standard has emerged for newline delimited JSON as a content-type.
Just use 'x-my-json-sucka' or whatever, just preface with x-
On May 23, 2012, at May 23, 20122:10 PM, Joshua Holbrook wrote:
Newline-delimited
it seems that the work on the client side to do streaming parsing gets
much harder
I don't understand? Parsing commas is hard? However you planned on
parsing newlines could parse commas instead.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
Which comma do you parse is the problem -- and then you are writing a JSON
parser.
I've used newlines in the past to separate JSON objects and think Ken's
approach makes sense. A new content type would allow a generic parser to
know the right thing to do.
To answer your original question, I have
The key is to avoid using something as a delimter that will show up as a
matter of course in JSON objects. Twitter uses \r\n pairs for their API
(which I believe they serve up as application/json). They may also include
blank lines. This format can be parsed using something as simple as the
I wrote a json parser and I dont get the issue here!
I guess it must be a crappy one :) push pop!
Nuno
On Wed, May 23, 2012 at 11:27 PM, Ken ken.woodr...@gmail.com wrote:
The key is to avoid using something as a delimter that will show up as a
matter of course in JSON objects. Twitter uses
13 matches
Mail list logo
