couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: REST, Hypermedia, and CouchApps
Date Wed, 25 Feb 2009 14:23:35 GMT

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.

>
> I've tried to keep the CouchApp project out of the way of CouchDB,
> because I'm trying to be humble and not effect CouchDB with this
> experiment. Certainly we don't want to give people the impression that
> CouchApps are the only way to use CouchDB. I've gone out of my way
> whenever possible to make that clear.
>
> OTOH, the CouchApp project is basically designed around CouchDB, to
> fit it like a glove. The guiding principle, is that if it can't be
> deployed to every unmodified CouchDB server, it's not a CouchApp. As
> more people start to develop for CouchDB using CouchApp, things like
> the index of available apps become more helpful. The question becomes
> practical:
>
> Currently listing the available apps takes quite a few HTTP requests
> (Futon has to load all the design documents in each DB). If CouchDB
> wanted to support CouchApps more directly, it could provide a JSON
> resource at /db/_design/ that lists all design docs, along with the
> absolute path to their start page, if they have one.

Couldn't we load up all the design docs using _all_docs? 
startkey="_design/"&endkey="_design0"&include_docs=true?

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 also want to be clear that there are more ways to write portable,
> standalone CouchDB apps than by using the CouchApp project. However,
> CouchApp tries to be the simplest thing that could possibly work, for
> getting files from your text editor into a design document. So
> hopefully it can be a basic helper that people find useful even if
> they aren't interested in the higher level helpers we've been adding
> to it.
>
> The CouchApp code is released under the Apache 2.0 license, so if
> there were community interest in bringing it into the CouchDB project,
> it would not be hard.

I think it should be an Apache subproject.

>
> I'm hoping to gauge the larger CouchDB community interest in
> CouchApps. I know some people are mostly interested in Couch as a
> giant data store, and would never plan to expose it to end users via
> HTTP. Even in that case, a CouchApp would be an ideal way to add
> in-house browsing and analytics to a database. The idea of CouchDB
> endorsing a particular application framework is a little troubling to
> me, which is why I'm trying to limit the points of endorsement to
> those which could easily be used by applications which are developed
> entirely without the CouchApp helpers.
>

I think we shouldn't make CouchDB a slave to CouchApp, but I think a  
close relationship between the 2 is beneficial for all. CouchApp  
should push CouchDB to make practical design choices, but CouchDB will  
have to always keep the general needs in minds.

-Damien

Mime
View raw message