On Thu, Dec 11, 2008 at 12:58 PM, Damien Katz <[email protected]> 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 http://jchris.mfdz.com
