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 Thu, 05 Mar 2009 22:45:06 GMT
On Thu, Mar 5, 2009 at 12:38 PM, Christopher Lenz <> wrote:
> On 25.02.2009, at 06:16, Chris Anderson wrote:
>> The question raised by all of this is how closely do we want CouchDB
>> to be intertwined with CouchApp?
> In my opinion we should go out of our way to avoid the
> impression that CouchApps are the preferred/endorsed way to use CouchDB.

Definitely agree with you here, and I've felt this way for a while -
thanks for putting the Futon links in this perspective. I'll work on
factoring them out to a separate page, and then we can discuss methods
for making them available to users without making other uses of
CouchDB seem second-class.

> CouchApp links smell too much like an
> official endorsement of one particular method to me. Plus, the
> "Applications" column must be rather confusing for any CouchDB users who
> haven't played with the CouchApp concept yet ("Hum, how do I get my PHP
> scripts in there?" [not that anyone should be writing PHP scripts in the
> first place]).

Good point, agreed as above.

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

I disagree strongly here. I don't think it hurts CouchDB's focus as a
database to have the ability to render documents and views as non-JSON
formats. The same code paths that have been laid for these features
provide the groundwork for stuff like the proposed _update handler,
which will let application developers make CouchDB flexible about
accepting non-JSON input formats. As we expand the capabilities of
design documents we can also easily add migrator functions (a JS
function run on every document that has the chance to make small
changes to the format, for instance changing a timestamp format or
restructuring a JSON namespace to keep up with application changes.)

The main reason it's important that applications-as-design documents
are enabled by default, is that they can be deployed and distributed
using just CouchDB replication. When the application and the data
travel together, and are fully available to the user, innovation can
flourish. Standalone CouchDB applications have the potential to be
game-changers on the web. If CouchDB doesn't support them by default,
that potential becomes even more long-shot.


Chris Anderson

View raw message