[
https://issues.apache.org/jira/browse/COUCHDB-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176797#comment-14176797
]
Alexander Shorin commented on COUCHDB-2396:
-------------------------------------------
Few open questions:
- How does subscribing on changes against specific document is different from
subscribing on database changes feed filtered by specific document id? The
latter is already available and allows you to listen changes for multiple
documents, not just single one.
- Following the first question, how does it sane to listening multiple changes
feeds (aka open and manage multiple connections) for various documents while
you can do all the same using just only one?
- How does subscribing on view changes feed is different from subscribing on
database changes feed filtered by using specific view with following params?
What's your use case which gave you an idea to spread one single feature
limited by it own resource across all the others (resources)?
> Provide ?changes=true for all GET requests
> ------------------------------------------
>
> Key: COUCHDB-2396
> URL: https://issues.apache.org/jira/browse/COUCHDB-2396
> Project: CouchDB
> Issue Type: Wish
> Security Level: public(Regular issues)
> Components: HTTP Interface
> Reporter: André Gaul
>
> h2. Situation
> Assume you've made one of the following HTTP requests against a CouchDB:
> * GET /albums/foobar
> * GET /albums/_design/ddoc/_view/by_name?startkey=foo
> In a lot of applications, you're interested in the changes that happened
> since the last request or you even want to receive continuous/live updates
> (e.g., via [Server Sent Events|http://www.w3.org/TR/eventsource/]). Actually,
> that's what CouchDB's _changes feed is made for (and it does a good job in a
> few projects I maintain). CouchDB 2.0 seems to go a step further by providing
> a changes feed for views (according to a discussion with [~janl] on irc, see
> also [here|https://github.com/rcouch/rcouch/wiki/View-Changes]). However, the
> _changes feed is a bit hard to use if you want to get the changes for a
> specific request with all involved parameters (e.g., for the above view
> query).
> h2. Improvement
> From a user's perspective, it would be much simpler if the changes could be
> fetched for a specific request by simply appending _?changes=true_ and a
> _since_ parameter whose value was provided by the previous request, e.g. by
> * GET /albums/foobar?changes=true&since=4711
> * GET /albums/_design/ddoc/_view/by_name?startkey=foo&changes=true&since=4711
> Technically, the changes reply could consist of [JSON
> patches|https://tools.ietf.org/html/rfc6902].
> This kind of _changes_ feature would be great for all REST APIs in the
> context of (near-) real time apps. CouchDB probably has almost everything in
> place to support this feature and make life much easier ;). On the other
> hand, I can imagine that it requires a significant amount of work in
> CouchDB's internals.
> Since I'm not too familiar with CouchDB's internals, I'd like to bring this
> idea up for discussion here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
