[
https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793237#action_12793237
]
Paul Joseph Davis commented on COUCHDB-604:
-------------------------------------------
I've met the Yeti. His name is Yajl. He's quite friendly, but no one ever
really mentions the SAX thing much. Cause no one ever really produces partial
JSON documents. Cause there really aren't that many SAX parsers. Cause as it
turns out, SAX is a huge friggin pain in the butt. Granted this 'push parser'
sounds more like a pull-dom parser. Either way, this discussion on commas is
pretty weird for being about commas.
The validity of that response with that content-type is debatable. AFAIK theres
nothing in the specification that says you can't repeat values in a JSON
stream. And there are parsers that allow for parsing multiple values. The XMPP
'infinite document' is just a clever hack around a format that explicitly
denies repeated documents.
If someone wants commas in that stream, then they should feel free to write a
patch. But comma's have nothing to do with non-blocking i/o or other such
things.
Cheerio!
> _changes feed with ?feed=continuous does not return valid JSON
> --------------------------------------------------------------
>
> Key: COUCHDB-604
> URL: https://issues.apache.org/jira/browse/COUCHDB-604
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Affects Versions: 0.10
> Reporter: Joscha Feth
> Priority: Trivial
>
> When using the _changes interface via ?feed=continuous the JSON returned is
> rather
> a stream of JSON documents than a valid JSON file itself:
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]}
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true}
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]}
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]}
> to be valid there needs to be a root element (and then an array with commata)
> like in the non-continuous feed:
> {"results":[
> {"seq":38,"id":"f473fe61a8a53778d91c38b23ed6e20f","changes":[{"rev":"9-d3e71c7f5f991b26fe014d884a27087f"}]},
> {"seq":68,"id":"2a574814d61d9ec8a0ebbf43fa03d75b","changes":[{"rev":"6-67179f215e42d63092dc6b2199a3bf51"}],"deleted":true},
> {"seq":70,"id":"75dbdacca8e475f5909e3cc298905ef8","changes":[{"rev":"1-0dee261a2bd4c7fb7f2abd811974d3f8"}]},
> {"seq":71,"id":"09fb03236f80ea0680a3909c2d788e43","changes":[{"rev":"1-a9646389608c13a5c26f4c14c6863753"}]},
> in short this means that if someone does not parse the change events in an
> object like manner (e.g. waiting for a line-ending and then parsing the
> line), but using a SAX-like parser (throwing events of each new object, etc.)
> and expecting the response to be JSON (which it is not, because its not
> {x:[{},{},{}]} but {}{}{} which is not valid) there is an error thrown.
> I can see, that people doing this line by line might be okay with the above
> approach, but the response is not valid JSON and it would be nice if there
> were a flag to make the response valid JSON.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
