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.
