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
