couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dynnamitt <>
Subject Time to ReReduce (not ReWrite)
Date Fri, 02 Apr 2010 15:34:45 GMT

First of all: Congratulations with a fantastic DB ! 
CouchDB is just fantastic and could very well be one of the final web
solutions before we all reach Nirvana together in harmony :)

Its just a tiny API Cleanup/Reduction (!) away from beeing truly perfect:

The API surrounding the DesignDoc is overly complex ..and messy.
A ReWrite Module IS NOT fixing this; its only making CouchDB even harder to
learn and
probably not good for performance either. 

Before CouchDB "goes 1.0" there should be a simpler (alternative) API that
makes CouchDB an even better AppPlatform

Why not try this API "reduction" :

1) Create a new reserved key that is "db/-/" . This will replace the old

2) Do not break old clients ; keep the old urlSystem as long as needed.
"/db/_design/**" should be keept for backward compability.

3) This new uri path (-) will ONLY contain DesignDocName and ViewName ! (
away goes ugly _show, _view and _list    )

4) The very CONFUSING "concepts of Shows and Lists" is joined into one new
consept: Transfomations. 

5) Transformation "id" is appended to any resource URI as Extensions!

This will give users a GET API like this:
http://couchDB/mydb/-/app1/view1    ( a pure json view , named "view1" )
http://couchDB/mydb/-/app1/view1.html   ( view1 is transformed with func
"html" )
http://couchDB/mydb/-/app1/view1.atom   ( view1 is transformed with func
"atom" )
http://couchDB/mydb/123 ( a pure json doc )
http://couchDB/mydb/123.app1.html ( a doc transformed with func "html" in
DesignDoc "app1" )

The funcs named "html" or "atom" must now be able to handle BOTH types of
resources ofcouse (docs and views). Just like the Reduce/ReReduce function
These funcs is stored in the app1 DesignDoc like the "list" and "show" funcs
are today

6) The only uglyness left is perhaps the .app1. (when transforming Docs
But wait; how about giving a DesignDoc named "default" special meaning.
so. If I request ;
then CouchDB will append ".default" for me.. since its easy to spot that its
so I get in fact;


Compare these "new" URLs with the old ones,
and you will see that these are 
a) prettier and shorter
b) Alot easier to understand (for me at least)
c) More restful.
d) The resource id (docName/viewName) is now further to the right in the URL 
e) The Transformation id (ListName/ShowName) is less significant compared to
the resource id
f) It should be backwards compatible 
g) The "real" resources should be "more apparent" (Relax! Its only docs and

Closing remarks:
* The fact that CouchDB 0.12 now has ReWrite only makes the product more
complex , it does not
address the REAL problem: a messy API (in very importent parts)
* The "-" (dash) is just my humble suggestion. It would be even smarter to
use "_v2" (and reserve a few others while you are at it:)
* I probably did forgot some details.. 

Please compare:

/db/_design/sofa/_list/atom/recent-posts   "vs"

/db/_design/sofa/_view/recent-posts   "vs"

/mydb/_design/default/_show/html/72d43  "vs"

Didnt this make more sense ?

K.I.S.S. from very relaxed
Kjetil Dynna Midtlie


View this message in context:
Sent from the CouchDB Development mailing list archive at

View raw message