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 Wed, 25 Feb 2009 22:33:06 GMT
Thanks for the interesting replies, everyone! Responses in random order

On Wed, Feb 25, 2009 at 6:23 AM, Damien Katz <> wrote:
> On Feb 25, 2009, at 12:16 AM, Chris Anderson wrote:
>> The question raised by all of this is how closely do we want CouchDB
>> to be intertwined with CouchApp?
> I think making sure CouchDB can support everything CouchApp needs is
> important, I think CouchApp can be huge. And other app frameworks can easily
> take advantage of the goodness too.
> But I think the integration can go to far, CouchDB shouldn't know about
> CouchApp explicitly, because every special case is new baggage that is
> useful only to CouchApp, but that everyone must pay for.

Thanks for putting it more clearly than I could. CouchApp-instigated
changes to CouchDB should be held to scrutiny to ensure they don't
have negative repercussions for more database-y use cases.

As far as becoming a subproject goes, BenoƮt C and I are both excited
by the idea. I think there's no hurry, and CouchDB is in a bit of
crunch for 0.9, so waiting might be best, but it doesn't hurt to start
the ball rolling. (Assuming the community agrees with the idea.)

On Wed, Feb 25, 2009 at 2:35 AM, Patrick Antivackis
<> wrote:
> If it can be more intrusive, the best would be (at least for html document)
> a regexp like function in CouchDB to set the <base> allowing to use relative
> url afterwards.

I don't think it is wise for us to process attachments like this.
Certainly it breaks the non-CouchApp use cases, and getting it right
would be non-trivial. Also this sort of thing is practically begging
to turn into essentially what _show already is.

> An other improvement (still intrusive) is to permit to define in _show and
> _list a list of view/list/ whose results would be passed to the _show and
> _list called function in order to give more power to these functions.

I think its pretty crucial that show and list remain 1:1 mapping
functions from docs and views to html (or other) output formats. In
the current implementation, each view row is sent to the client and
then forgotten by the server before the next is rendered. This means
that memory usage is flat no matter how many rows a list renders.

I think CouchApp will follow these constraints in the long-term,
because if we break them, people can write apps that fall apart with
lots of data or lots of traffic. There are things you can't do with
_list and _show, but you can do enough, I think, for it to be

On Wed, Feb 25, 2009 at 4:33 AM, Robert Dionne
<> wrote:
> Chris,
>  I can't speak to the general relationship between CouchApp and CouchDB
> other than to say CouchApp is awesome, I've been following progress and one
> of the big advantages I see is the ease of deployment in  large enterprises
> or amongst multiple collaborators in small groups. Treating the app itself
> as just part of the data base is a big win when one considers for just a
> second the gymnastics often required when configuring software. Not being a
> web developer I can't say much more. See below.

Thank you for the vote of confidence!

> Views are specified by design documents and run over all documents in
> a database. Why can't they run over design documents, across databases and
> also over other views?

The view model is very simple currently. Essentially, a map view is
the result of running CouchDB replication through a transformative
function. Views can run over design docs, but running them over other
databases or view results would be a major change. We'd like to see
this, but I think it's properly classed under the header of alternate

On Tue, Feb 24, 2009 at 9:16 PM, Chris Anderson <> wrote:
> One way to fix this it to give the resources made available by a
> design document a common root. This means we can use hrefs like
> "_show/docid" to link to a show function from an attachment.  So we
> get paths like this:
> /db/_design/foo/_view/bar?limit=10
> /db/_design/foo/_show/docid
> /db/_design/foo/index.html

As noted by the others on this thread, one nice thing about this
change is that it allows a proxy to be configured so that requests to automatically appear at
/myapp/_design/myapp/foo/bar. If the links within the design root are
all relative, the application could potentially work even without any
changes (as long as it only relies on application resources - the JSON
doc api would be made inaccessible through such a proxy, which might
be good for some applications anyway...)

There seems to be support for this fairly major API change from a few
users. Would anyone like to speak against it?

On Wed, Feb 25, 2009 at 6:23 AM, Damien Katz <> wrote:
> Couldn't we load up all the design docs using
> _all_docs?startkey="_design/"&endkey="_design0"&include_docs=true?

That would certainly lower the number of require requests. I thought
for a minute about using a temp_view for this, but there is no way to
restrict them to run on only the design docs, so the overhead could be
tremendous. I still think it'd be trivial to implement as part of a
view-like response from /db/_design/

> Also, I think if you want a really fast, slick interface for organizing
> couchapps on a large scale, you'll need a separate database to aggregate all
> the db apps into one place. Think 1000s of dbs. Lotus Notes does something
> like this for it's "database catalog".

I'm a little wary of something like a registry, because it can get out
of date. I'll put in a ticket to cut down on the # of requests Futon
makes to populate the Applications column. If this ends up creating
the /db/_design/ resource I think that'd be a nice side-effect of my


Chris Anderson

View raw message