[ https://issues.apache.org/jira/browse/COUCHDB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793257#action_12793257 ] Damien Katz commented on COUCHDB-604: ------------------------------------- Wow, lots of comments on this one. I originally implemented this as a single JSON stream, it was switched to newline separated json objects for ease parsing by clients. I don't have an opinion one way or the other, but the thing starts to bothers me is the culture offering more options so that everyone can have it exactly as they want it. The stems from the increasing "texture" of the API, and what must get documented and tested, and the burden of what must get implemented for those who want to make compatible CouchDB implementations. I tend to favor simpler APIs to the point of occasionally pushing some of the complexity to the client to ensure the server itself isn't completely overloaded with complexity and options. > _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.