couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jedediah Smith <>
Subject Re: 1.0.0 wishlist/roadmap
Date Fri, 12 Dec 2008 09:31:08 GMT

Using the actual view functions would be awfully convenient. People are 
going to want comet feeds of their fancy generated views. Having to 
rebuild them on the client would be a let down.

How about a view parameter that adds a seq field to each row and orders 
results by seq instead of key (but you still get the key)? Could that 
even work for reduced views, where seq would be reduced with max()?

With any comet scheme, wouldn't you want to return seq with all DB reads 
so that you can sync up your comet gotten data with non-comet data?

Chris Anderson wrote:
> 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.

View raw message