intertwingly

Christopher Lenz: CouchDB views are basically highly efficient on-disk dictionaries that map keys to values, where the key is automatically indexed and can be used to filter and/or sort the results you get back from your views. When you “invoke” a view, you can say that you’re only interested in a subset of the view rows by specifying a ?key=foo query string parameter. Or you can specify ?startkey=foo and/or ?endkey=bar query string parameters to fetch rows over a range of keys. It’s also important to note that keys are always used for collating (i.e. sorting) the rows.

Jacob Kaplan-Moss: The wins go deeper than APIs, though. Think about what it would take to add load-balancing to CouchDB. I’ll give you a hint: perlbal. Or what about adding a transparent caching layer? Try Squid.  HTTP is the lingua franca of our age; if you speak HTTP, it opens up all sorts of doors. There’s something almost subversive about CouchDB; it’s completely language-, platform-, and OS-agnostic.

Dan Sickles: I’ve always said that you don’t need an ORM if there’s no R.

To this, I’ll add that if CouchDB could efficiently compute an ETag† for startkey/endkey type queries by only accessing the index, this could be a big win.  Most shared-nothing applications would simply become a dispatcher, a few views, and a few templates.  The most complicating thing your application need worry about would be when you need to assemble a page using input from multiple views.

† yes, indeed, I am a broken record on this subject — get over it