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: Problem: 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. Solution: 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 "db/_design/". 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 only) But wait; how about giving a DesignDoc named "default" special meaning. so. If I request ; http://couchDB/mydb/123.html then CouchDB will append ".default" for me.. since its easy to spot that its missing so I get in fact; http://couchDB/mydb/123.default.html Nice?! 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 views!) 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/_v2/sofa/recent-posts.atom /db/_design/sofa/_view/recent-posts "vs" /db/_v2/sofa/recent-posts /mydb/_design/default/_show/html/72d43 "vs" /mydb/72d43.html Didnt this make more sense ? K.I.S.S. from very relaxed Kjetil Dynna Midtlie (Dynnamitt) -- View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4843170.html Sent from the CouchDB Development mailing list archive at Nabble.com.
