couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: 1.0.0 wishlist/roadmap
Date Thu, 11 Dec 2008 21:15:15 GMT
On Thu, Dec 11, 2008 at 12:58 PM, Damien Katz <> wrote:
> I'm thinking of removing the _all_docs_by_seq HTTP view and replacing it
> with something that will allow for more flexibility and also allow for Comet
> like events, by providing a filter function that finds documents that meet a
> criteria, and to be notified immediately when new documents are saved that
> meet that criteria. This is meant to be used by the replicator and external
> indexers, but to also try to make it be like a regular view and while
> supporting all the other stuff is pointlessly complex.

I think if we support an HTTP resource that provides GET and HEAD
responses, representing a range of documents, in a JSON format like
the one views use now, I'd call it a view.

GET /db/_by_seq?since=200&full=true

could return all changes since seq 200. And if a client makes the
request when the db seq is 150, the response will just hang (like
Comet) until 51 seq #s are incremented. We could optimize with a batch
parameter, so the client could request that CouchDB never send less
than N seqs in a single response. Or there could be an option to keep
the connection open while waiting for new seqs to increment. (I think
I'm describing a system Damien remarked about in IRC.)

I guess I think there's some gain to be had if the replication stream
JSON format is similar to what comes back from a view request. For one
thing, it would make it simpler to implement other non-CouchDB
replication clients, which is a good thing.

Chris Anderson

View raw message