Good work Chris. I went ahead and made the optimization so it only
uses the os process while actively filtering changes.
My only suggestion is to change the "filters" field to
"changes_filters", so it's a little more clear what its filtering.
Also, I think it would be cool to be able to pass params to the filter
functions too, either through the query string or via POST. For
example in the demos, to allow users to subscribe to any number of
channels in chat, or just get changes on the displayed month in the
calendar.
-Damien
On Jul 20, 2009, at 1:17 AM, Chris Anderson wrote:
Devs,
I've just committed a patch (r795687) that adds the ability to filter
_changes requests with a JavaScript function.
The function signature is:
function(doc, req, userCtx) {
return (true or false);
}
When it returns true (or something truthy, like a non-empty string or
a non-zero number), the change is passed along to the user, otherwise
it is skipped.
The filter functions are stored on design documents under the
"filters" field. The current best source of documentation is the
changes.js test.
To query changes with a filter, the syntax is like:
GET /db/_changes?filter=ddocname/filtername
The biggest problem with this patch is that it uses a JavaScript OS
process per connected filtered listener. Fixing this is an
optimization as it won't effect the API, which is why I'm comfortable
committing this.
I'd appreciate some review to make sure the implementation is on the
right track.
Cheers,
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
