Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of ulises.cervino@gmail.com
 designates 209.85.218.11 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=DveKqTjbCAgX7kQrhYEYl0Y58/k0M2ifj2lJ/qkdtmEONZFzPugngbtJR0vfGewzrD
         DsCx2rF5woegxc5HmERdm6tJFXJpMCWFiLK3pQ1biVbknLkBQGpnA6rYzZ1L6+7wAW5T
         gbchB8+zq1Bkc9xKL4THwvkxry38Mq5HbZr1w=
Message-ID: <226d73360901190035w47021a63p9e54459c0d6b3ea9@mail.gmail.com>
Date: Mon, 19 Jan 2009 08:35:37 +0000
From: Ulises <ulises.cervino@gmail.com>
To: dev@couchdb.apache.org
Subject: Re: all_seqs stream (was Re: Update notifications including update
 sequence)
In-Reply-To: <e282921e0901190030x13133bbha5152ad87b89c964@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e282921e0901182355t12890a06jd7e8bf8f9bcc5e8a@mail.gmail.com>
	 <e282921e0901190019s27d1d7ebyb734e2a9ce8b726e@mail.gmail.com>
	 <226d73360901190021j267cb586tdf7375dbc7a94730@mail.gmail.com>
	 <e282921e0901190030x13133bbha5152ad87b89c964@mail.gmail.com>

> 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