From user-return-7894-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sun Dec 06 12:31:26 2009
Return-Path:
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: (qmail 62271 invoked from network); 6 Dec 2009 12:31:25 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 6 Dec 2009 12:31:25 -0000
Received: (qmail 91087 invoked by uid 500); 6 Dec 2009 12:31:24 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 90983 invoked by uid 500); 6 Dec 2009 12:31:23 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 90973 invoked by uid 99); 6 Dec 2009 12:31:23 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Dec 2009 12:31:23 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of matteo.caprari@gmail.com designates 209.85.219.225 as permitted sender)
Received: from [209.85.219.225] (HELO mail-ew0-f225.google.com) (209.85.219.225)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Dec 2009 12:31:15 +0000
Received: by ewy25 with SMTP id 25so2275332ewy.25
for ; Sun, 06 Dec 2009 04:30:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:from:date:message-id
:subject:to:content-type;
bh=wycvvWtdkx/hntYqBy5hCpMIF+QIbKT85FephCOhIP8=;
b=YNQkfjdu9Utj9O3dVFmCWOQsapheTaF1y3fKxAH/DcrQaRqFL1OjqxVvCIOAQoRNtM
Ipe8GJI99nHOZ1GHUaZNy623OTlUKy7eh4TUZAgYpkt2G1fTTB2YY312aoPLxNOBABkb
TxmaJKExlMoU412Q3sOYiMjqG/4ErOzf2Sb5A=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:from:date:message-id:subject:to:content-type;
b=Zdl8LnL8nrdYvs4SQHeSLOmtlsWV3hMwmR+1O+6AVVJ8OzR+cAKxLKj8sSDYfysow1
29t7VFrc7ecyNIibltFBR/xrc6j2CQaHsndw5Aqm/PwXShUl5RZLfTgglSXYccHyTGK7
n8dJC4MX+mOfdQbx6LFpD9HD1TY8wXJql86vc=
MIME-Version: 1.0
Received: by 10.216.90.136 with SMTP id e8mr1816394wef.110.1260102655107; Sun,
06 Dec 2009 04:30:55 -0800 (PST)
From: Matteo Caprari
Date: Sun, 6 Dec 2009 12:30:35 +0000
Message-ID: <1bca98390912060430k44f56df7h62a7bff7b8fac71e@mail.gmail.com>
Subject: ho to notify a client that it's time to update his views?
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
X-Virus-Checked: Checked by ClamAV on apache.org
Hi.
While my couchdb application is very quiet most of the time, sometimes
there is a burst of activity:
tens or hundreds of documents are created and updated in few seconds.
There are many users logged on the system, but each burst is relevant
only for one of them.
When this bursts happen, I want to suggest the user's browser to
reload his views. Clients are connected to a queue via cometd,
messages can be pushed to them.
An approach may be to write a _changes listener that sends a message
to a client when it thinks best, but there's a catch: to know which
client to notify, the proces would either have to download the
documents or I'd have to create one listener for each user, which
would mean one http connection per user. Not that http connections are
a bad thing, but I'm still shy with too many of them around...
Another approach would be to execute a view that counts the documents
for each user and sends a message to the ones for which the count has
changed since last execution.
I'm sure I'm not seeing better solutions. Suggestions anyone?
Thanks!
Notes:
Connecting each client to the _changes API is not welcome because each
client is already using one connection with a comet server.
Also, there are different classes of documents associated with
different views, and I'd end up with multiple connections to
differently filtered _changes.
Of course the processes that create and update the documents know
which user owns the document. I could have them send a message when
due, but I was hoping to keep generators and consumers as decoupled as
possible, with couchdb in the middle.
--
:Matteo Caprari
matteo.caprari@gmail.com