couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: REST, Hypermedia, and CouchApps
Date Mon, 09 Mar 2009 18:04:56 GMT
On Mon, Mar 9, 2009 at 10:42 AM, Paul Davis <> wrote:
>> Following that, the _list/_show bits seem like they would fit quite
>> nicely into such a framework as a poster child of the modular couch.
>> And we could even ship couchdb with _show/_list turned on by default
>> if the community so desires it.

I think they are a pretty good poster child as it is. Currently to
disable them you need only comment out two lines in the ini file. The
code could be arranged in different directories but if we want to do
that it can wait for OTPification.

On Mon, Mar 9, 2009 at 10:01 AM, Christopher Lenz <> wrote:
> But how is that relevant to applications that do *not* follow the CouchApp
> model, but rather have a traditional web/app-server sitting in front of
> CouchDB?

I've been thinking about examples of this for a couple of days. There
are a few that I've found that are perfect for CouchApps even in a
middleware deployment. One of them is document-signing, as is being
discussed on the list right now. It'd just be a matter of a show
function, which could return a canonical JSON string for a given JSON
document (or subfield of that document) to be signed by the client.
Write once, reuse in any Couch, no messy Erlang patches or custom
config to deal with. I'm sure there are more examples along these

Another example (that Paul has already experimented with) is
server-side filters. Say I want all the recipes that involve cilantro
and strawberries. For ingredient in ingredients emit(ingredient,
ingredients) and filter in a list function (that serves JSON) to save
bytes over HTTP. It's just another tool in the pragmatic
Couch-developers toolkit.

Thanks for the support, Chris, even though it's not your use case.
>From my vantage point CouchApp style development is garnering a lot of
interest, some of it quite heavyweight.

My strategy for committing will be - commit to the branch I started
today. Notify the dev and user lists about the breaking change to view
urls. Merge the branch to trunk. I don't see much point in waiting
between the notification of the breaking change and the merge - people
who want time to convert their client libraries can hover at the
pre-merge revision until they are ready to leap to 0.9.

Does this seem sane to you all?


Chris Anderson

View raw message