> The idea behind this is to unify the replication and standard http > client interfaces for updates streams, so for instance GET replication > (incrementally updating a db that's current as of seq 200) could work > via a request like: > > /db/_updates?since=200&include_docs=full > > And an _external that wanted to see every (or a subset) of updates > (for instance a Full Text Indexer) could use the same mechanism to > incrementally maintain an index.
That's rather interesting and beg the question whether this wouldn't render _external obsolete? You could simply manage your own ex-_external as a separate process that kept this comet notification channel open. > Update streams (especially filtered ones) are one of the most powerful > tools CouchDB offers. For instance, with filtered streams, you can > very easily make docs into persistent state-machines. And the > Comet-style requests mixed with client-specified filters makes it very > easy to write event-driven browser apps. It does indeed. I'm already thinking RSS, IM Server in couchdb anybody? The options this might open are rather interesting. U
