Hi Jan, > 6. and to be clear, we are talking about: 1. _show & _list 2. _update funs, > 3. rewrites
Thank you very much for the clarification. As you can imagine, it is greatly needed to plan our own developments. > 5.We invited the CouchApp community to step up and build a future-ready > version of CouchApps, complete with a design direction and own mailing list.. > Nobody stepped up, and at the end of the day, a project goes where developers > can spend time. If I may say so, I doubt a participative process could have work this way with no facilitator in charge from the very beginning. But be sure that I’m not here to blame anyone. And since we don’t have a time machine, this would be useless. So, let’s focus on the future. > In terms of ease of building web apps: a Node.js process running next to > CouchDB is only minimally more setup hassle and gives you (…) Right. In several of our applications, we already have an ExpressJS layer in front of CouchDB in order to circumvent its limitations/constraints. Transforming `_show` and `_list` into ExpressJS middleware shouldn’t be that hard… except for the lack of `userCtx`. How do you plan to manage users in this new architecture? - Where will be the right place to handle session cookies? in CouchDB or in NodeJS? - If it is in NodeJS: - Will `proxy_auth` become the only authentication mode? - Will `_users` database become obsolete? - How per-doc access-control will be designed? Only with users defined elsewhere? On a more theoretic side, I am a bit sad of the disappearance of `_show` and `_list` since, by providing the building blocks to content negotiation (when used with rewrites.json « hacks »), they made CouchDB the ultimate illustration of HTTP and REST concepts (even better than Atom Publication Protocol!). I was so impressed by this… And I was so excited when I first provided CSV, FreeMind, BibTeX (depending on the domain) alternate representations… May I hope that in the future content negotiation could be made first class citizen in CouchDB again (even in a better – less hacky – way)? As for the disappearance of rewrites… I was just discovering the potential (and the bugs) of the brand new JavaScript rewrite… As soon as it is born, it has to die. Wow. > // for the time being, we’ll keep validate_doc_update and filter functions, > but plan to replace them with per-doc access control and Mango schema > enforcement. The idea of design docs, or attachments on documents are not > going away. OK. Just to be sure (because I’m not sure to understand what « NoJS mode » means exactly): - Will JavaScript views still exist in CouchDB 3? - If the answer is no, will Mango be the only option or will it be still possible to implement Erlang map/reduce views? I ask this because we put much love into our CouchDB views and succeeded in getting quite efficient implementations for things that did not scale on PostgreSQL. These views are clearly out of the scope of Mango, and would probably need good skills in Erlang to be ported… Regards, Aurélien
