couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: filter for _changes
Date Tue, 21 Jul 2009 07:33:22 GMT
On Mon, Jul 20, 2009 at 11:53 AM, Damien Katz<> wrote:
> Good work Chris. I went ahead and made the optimization so it only uses the
> os process while actively filtering changes.

Thanks, I can't wait to take a look at that.

> My only suggestion is to change the "filters" field to "changes_filters", so
> it's a little more clear what its filtering.

I guess I like "filters" because it's vauge... heh. Because I've been
thinking forward to uses like a security filter. Eg you might have the
same function but use it in different ways. I admit I haven't thought
this through yet, but I feel like there's something there. I'll
marinate on it...

> 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.

I think you can do this currently, the test suite should ensure that
query parameters are passed into the JavaScript function.

In reply to Matt's comment on the URL path, I've been thinking it will
eventually end up in both places, I did this one first because it was
easiest to implement. Adding the ddoc path should just be a simple
call into this. There's also a potential future feature to (A) add a
style=include_docs option to the _changes API and then (B) to add the
ability to run that output through a _list function.

Imagine being able to make Toast-like realtime chat just by appending
<li> elements to an HTML <ul> in an iframe. Real time chat without
Ajax. ;) Anyway, that's just thinking forward along the lines of what
would be easy to implement from here.


> -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

Chris Anderson

View raw message