On Thu, Jan 31, 2013 at 5:52 AM, Randall Leeds <[email protected]> wrote: > On Thu, Jan 31, 2013 at 2:42 AM, Jason Smith <[email protected]> wrote: >> On Sun, Jan 27, 2013 at 7:49 PM, Dave Cottlehuber <[email protected]> wrote: >> >>> 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? >>> >> >> The problem on my mind is quite modest: assess the feasibility of some kind >> of CouchDB+Node.js hybrid. I want to see how that changes build issues, and >> just generally see how it feels. > > That's not a problem statement, but it implies there's a problem with > "build issues". > >>> >>> 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" >>> >> >> I am not familiar with cpm however I am not thinking at all about building >> applications. In fact my goals are 100% compatibility with CouchDB 1.x. >> That is why I simply swap out the couchjs program. > > I'm guessing this is an imaginary "couchdb package manager". Something > like a .cpmrc would list the couch that packages might get installed > to (whether they be couchapps or other addons). > >>> 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. >>> >> >> That is out of scope with regard to the nodejs_couchdb branch. > > Good. I think that's wise. > >> >> >>> 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. >>> >> >> Yes, exactly. > > I'm not sure I believe that Node is actually more widely packaged than > SpiderMonkey. However, there is a good place to go for a summary of > availability of NodeJS via package managers here: > https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager > > I could find no equivalent for SM. > >>> 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: >>> >> >> Frankly I think performance should be a CouchDB 2.x feature. People want to >> change the view server model. People want to add more JS tooling, such as a >> better signup workflow. I have no opinion about all of that. However my >> work should inform those discussions because it elucidates how those tools >> might be implemented, and it might hint at some obviously good or bad >> directions. > > I think there may be great opportunity for some CLI management tools, > likely using node, which are independent of the couchjs implementation > but, if bundled, would suggest that node all the way through would be > more sensible. > > Nice work, Jason. I'm still hesitant, but I also think this could be a > good direction. > > For example, another direction to explore, which may be *even simpler* > than trying to include V8 or demand node be installed, is just to > bundle SpiderMonkey 1.8.5 in the source and drop support for previous > versions. Leave it to distros to link to their version *if they have > one* if they care about not bundling dependencies. > > I believe this is possible, but I would want to run it by legal. I > reason that since js1.8.5 is licensed under MPL 1.1 [1] and Section 6 > makes clear that code may be used under the terms of subsequent > license versions*. That means we could include js1.8.5, replace the > MPL 1.1 with MPL 2.0 [2], include MPL2's Exhibit B "Incompatible With > Secondary Licensenses" Notice (thereby revoking the GPL > compatibility), and bundle it with Apache CouchDB. + > > * One question would be about how the MPL 1.1 says only "Netscape" may > issue new versions, but the MPL is now owned and maintained by > Mozilla, does that mean that MPL 2 counts in the Section 6 clause. I > suspect the answer is "yes". >
That whole process sounds like not a lot of fun. > + Standard IANL disclaimer applies heavily. > > [1] https://www.mozilla.org/MPL/1.1/ > [2] https://www.mozilla.org/MPL/2.0/
