Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <47E2A491.7080409@theopenlearningcentre.com>
Date: Thu, 20 Mar 2008 17:53:21 +0000
From: Alan Bell <alan@theopenlearningcentre.com>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: couchdb-user@incubator.apache.org
Subject: Re: IMAP IDLE and realtime views
References: <47E24262.50801@theopenlearningcentre.com>
 <e282921e0803200958n63bca2cfp6f89a7907cfd5ece@mail.gmail.com>
 <6b6419750803201011o1cd7d5fje892d178dd53f64d@mail.gmail.com>
 <B5545187-56F3-4A5A-A235-59B4002BD385@gmail.com>
In-Reply-To: <B5545187-56F3-4A5A-A235-59B4002BD385@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

that sounds exactly what I was hoping for. No hurry on it, I just wanted 
to get it on the roadmap.

Alan.

Damien Katz wrote:
> Triggering on view changes is going to be really difficult to get 
> right. It might happen in the future, but don't look for it anytime soon.
>
> But I think providing a COMET like http service for monitoring 
> database updates will get you most of the way there. The idea is the 
> client makes a request, but the server doesn't respond until something 
> n the database actually changes. I don't know about IMAP and IDLE and 
> if this will work for that, but this is what I had in mind.
>
> The first time you'd simply make an HTTP request, something like this:
>
> GET /dbname/_change
>
> And it returns the database update sequence #:
>
> {seq:3412}
>
> Then you'd query your views and display them to the user. To monitor 
> for changes, do a similar request with the last known seq #:
>
> GET /dbname/_change?seq=3412
>
> Then the server will hold that HTTP connection open, waiting for the 
> database to change to higher seq#. Once it changes, the server will 
> send the new seq# back to the client:
>
> {seq:3413}
>
> If the database already is a higher seq #, it returns the higher seq 
> back immediately. Then the client knows something has changed in the 
> database and can query the updated views.
>
> The problem is the client doesn't know what has changed, so it 
> generally will have to re-query all the open views.
>
> I just had an idea, the user could provide a javascript function in a 
> POST (instead of the above GET), and each updated document is fed into 
> that function. It's still a COMET request and the flow is the same, 
> except now only when the function returns true is the client is 
> alerted an interesting document has changed. That could make things 
> more efficient for the clients.
>
> -Damien
>
> On Mar 20, 2008, at 1:11 PM, Patrick Aljord wrote:
>
>> I think it's planned to be able to place "hooks" in views so that
>> every time a view is updated it can start a job such as "create
>> thumbnails for each new picture attachments with imagemagick" or
>> anything else really. For now you can use a cron job that check if a
>> view has been updated periodically and use jabber or anything that
>> makes the job.
>
>