Hey all, I've been working on merging the view changes functionality from rcouch into CouchDB. I've made a few (hopefully) uncontroversial tweaks, but I'd like to build some consensus on what the API should look like before I go much further.
First of all, the view changes in rcouch endpoint looks like: /:db/_changes?filter=_view&view=:design/:view I'd suggest changing this to be something like: /:db/_design/:design/_view_changes/:view or possibly /:db/_design/:design/_view/:view/_changes Secondly, the merge adds a couple optional flags to the design doc (both disabled by default): 1) A flag to enable most view changes functionality 2) A flag to enable efficient querying of the view changes feed over a range of keys. (eg. if a view emits keys in the form of [year, month, day], you could query for all the changes which are between [2014, 3, 10] and [2014, 3, 20]) In rcouch, the flag for #1 is called "seq_indexed". That name may be a bit opaque to a user. Maybe something like "enable_changes"? #2 doesn't exist in rcouch (ie. enabling the "seq_indexed" flag in rcouch creates an extra index solely for view changes queries over a range of keys). I've talked with some people about making the key+seq index independent from the base view changes index. If they were independently optional, you'd be able to use the view changes functionality without creating an unused key+seq index (or vice versa). I've found that people generally think that it's a good idea, but if anyone disagrees, feel free to bring it up. I've already implemented the necessary changes for this behavior, but I need a good flag name. Maybe "enable_keyed_changes"? Otherwise, I think it'd be good to reuse the query string/POST body options from the normal _changes endpoint. Thoughts? Thanks, Ben
