couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 11:52:36 GMT
On Thu, Jan 31, 2013 at 2:42 AM, Jason Smith <jhs@iriscouch.com> wrote:
> On Sun, Jan 27, 2013 at 7:49 PM, Dave Cottlehuber <dch@jsonified.com> wrote:
>
>> On 26 January 2013 22:38, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> > On Sat, Jan 26, 2013 at 5:52 AM, Benoit Chesneau <bchesneau@gmail.com>
>> wrote:
>> >> On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <jhs@iriscouch.com> 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".

+ Standard IANL disclaimer applies heavily.

[1] https://www.mozilla.org/MPL/1.1/
[2] https://www.mozilla.org/MPL/2.0/

Mime
View raw message