couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: REST, Hypermedia, and CouchApps
Date Mon, 09 Mar 2009 17:40:29 GMT
On Mon, Mar 9, 2009 at 12:58 PM, Christopher Lenz <> wrote:
> On 05.03.2009, at 23:34, Jan Lehnardt wrote:
>> On 5 Mar 2009, at 21:38, Christopher Lenz wrote:
>>> Actually, I'd go even further, and suggest that the "show" and "list"
>>> features should be part of that CouchApp plugin, and not actually included
>>> with CouchDB itself. You really only need those features when you're
>>> developing CouchApp-style applications. Moving them into a corresponding
>>> plugin would help keep CouchDB itself lean and clean.
>> show and list are useful in the non-couchapp case. a list gives you
>> RSS/Atom feeds on views (say blog posts or events) for free. a show would
>> help you to mangle your data for other systems that e.g. like to consume
>> XML. I like that this can be done without a middleware layer.
>> I'm +1 on modularizing additional features on the Erlang level, but show &
>> list I'd consider core CouchDB and -1 on making them optional.
> "core" is a strong word for something where you just said "I like that this
> can be done without a middleware layer".
> I'm not convinced. I'm talking about the case where you already have
> "middleware" anyway -- if you don't, you have a CouchApp-style app.
> Generating Atom, HTML, and such is pretty darn convenient for me with Python
> and Genshi, I don't think moving that into CouchDB show/list functions will
> buy me anything. And since I'm hiding CouchDB itself behind that middleware
> I'd have to proxy the CouchDB responses through it anyway.
> Note that I'm just stating my opinion, I knew it'd be controversial,
> especially with the CouchApp fans :P
> I'm totally willing to accept the majority preference here, which seems
> pretty clearly in favor of show/list in core.
> Cheers,
> --
> Christopher Lenz
>  cmlenz at

My personal opinion is that we should strive towards making CouchDB
modular and easily configurable. (ie, no need to stop the server and
edit an ini file). As part of this work I could see having a contrib
directory of modules that are included in trunk and available on any
default install. Giving a nice page in Futon that was all pretty and
listed the available modules that could be enabled and disabled at
runtime would be awesome.

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.

Also of note is that the _show/_list code is pretty self contained and
doesn't affect the deeper internals other than to point out where
things could be made a bit more generic for reuse which has been
beneficial so far.

Paul Davis

View raw message