On 26 January 2013 22:38, Paul Davis <[email protected]> wrote: > On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau <[email protected]> wrote: >> On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <[email protected]> wrote:
This is a great thread & I'm wholly in favour of pretty much all of it. As is my wont, some points only slightly related to what people already said :D. But then we'd have 4 emails instead of one. # What is the *problem* we are trying to solve here? We have found a new hammer, it's very shiny. But we are not on the same page on why we need the hammer. # My problems 1. The hurdle for beginners could be lower. I could see a future where you can install apps as easily as: "cpm install garden20" and even leverage infrastructure like npm to do so. How in the back-end we transform those ddocs into the (to us) logical structure then becomes an internal issue. People can use npm modules to extend and develop their ddoc capabilities. Yes, this type of functionality exists today (commonjs modules, couchapp/erica/kanso) but it's not as easy as we could make it. 2. Extending couchdb with JS functionality, such as routers, authentication modules like passportjs could be npm easy. Today I think there's a handful of folk who would be able to do that. We would benefit hugely from making this step. I think this is the biggest win. There are node modules for almost anything, and a very hacker-friendly composable interface for most of them. If we can make the integration tight, that's a huge step forwards. Today it is definitely an additional layer, even if you use the externals API. 3. less build issues as node comes pre-packaged on all systems. This means swapping out couchjs for nodejs basically, re-using whatever protocol is already in place for the view servers, and making this Somebody Else's Problem. 4. finding a way to reduce the serialisation roundtrip cost between erlang/JSON/native JS. I guess that likely this is the most significant slowdown in the whole of couch, but we don't measure this stuff much (queue Russell). Some crazy-ish ideas: - storing raw/compressed JSON on disk instead of erlang terms (forget using erlang views in this case) - finding a way to freeze & thaw v8 JS objects so that there's not even a need to parse at all (lots of unsavoury possibilities here) - parsing the erlang terms directly in JS (avoid the erlang term -> JSON step) and keep both view server options Anyway food for thought, no code attached. A+ Dave
