CouchDB
  1. CouchDB
  2. COUCHDB-1894

Add experimental NodeJS query server

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.0
    • Component/s: JavaScript View Server
    • Labels:
      None

      Description

      Let’s clean up and merge Jason Smith’s Node.js query server into ASF land and ship it as opt-in and experimental.

      I’ve prepared a branch that does the following:

      • remove fancy extra features like app server handlers and the visual debugger support for now
      • make it a drop-in replacement for couchjs
      • bundle the code in src/couchjs-node
      • add a new query server language “nodejs” that people can use
      • include sandbox.js from https://github.com/KlausTrainer/sandbox.js (not hooked up yet)

      The query server is not installed by default and users can install them in two ways:

      1. from source:

      $ cd src/couchjs-node
      $ npm link

      2. from NPM:

      $ npm install couchjs # add @1.x.x for once the module mirrors CouchDB version numbers for forward compat)

      And then they can uncomment and update the [query_server] line in local.ini.

      • * *

      Open work items on the view server:

        Activity

        Hide
        Jan Lehnardt added a comment -

        Sorry for not addressing security concerns upfront, I knew they would be important and I rushed this ticket instead of taking the time to lay it all out.

        But first, this is a ticket for a branch for an experiment. This is not a suggestion that we should stop and change everything we do now. If we can’t experiment, we can’t progress, so I’d ask to take this with an experimental state of mind.

        This ticket is for review and iteration on an idea and some code.

        This code is an addition to the existing ways of doing things. It is off by default and opt-in and comes
        with large disclaimers.

        This view server runtime is not meant to replace couchjs today. It might never replace couchjs.

        If this is to ever replace couchjs, we need to start somewhere and this is as good a start as any. If there are other starting points, we should capture them in JIRA & branches as well.

        Getting this into more people’s hands via an experimental feature will allow us to make this good sooner.

        Dave brought up CORS as a good example of getting something experimental out that we can improve with user feedback once it is out. I hope we can do the same here and I really hope we can use this model a lot more in the future. This project has long suffered from trying to ship perfection.

        Finally, we already ship an off-by-default and totally dangerous view server that has access to all of CouchDB’s internals and we don’t sweat much about that. Let’s not start now.

        couchjs works but it is in dire need of improving. Mikeal’s original proposal for make it pipelined is now three or four years old. The fact that one has to juggle slightly scary JavaScript in an unfamiliar environment (SpiderMonkey on the cli is no really common), some scary C and some Erlang to iterate on the query server implementation lead to de-facto zero iteration and improvement. Sure we tacked on a few things and refactored the Erlang side of things, but the fundamental operation of couchjs & main.js has not changed in half a decade.

        I believe we can open this up to more experimenting and eventually to better software if we have a Node.js version of this.

        I have outlined the reasons why we want the default query server to be JavaScript in a recent mailing list post[1] so I won’t reiterate this here.

        What I would love to see here is the following:

        • definition of an acceptable secure code execution environment for view functions.
        • an improved communication method and protocol between the view server and CouchDB.
        • the ripping out of anything that isn’t necessary for views
        • the moving of features like _show/_list/_update etc. to a separate execution environment that is better suited for these kinds of access models. (the way we run _show & _list is really not ideal).
        • and finally and most importantly: other language implementations of the improved protocol and better separated features that we can then promote more prominently.

        This is a lot of work and we need to ship working software along the way. That’s why I propose to get this experiment going early and start from a point of minimal differences to the current model so we all have a chance of going on the journey of iterating and improving the view server and ultimately a core feature of CouchDB.

        Now, as for the security scenario in some more detail. I agree with Jason that we need to be very clear about what we mean with various terms and what we compare couchjs-nodejs too, especially because wrecking havoc with couchjs is not too hard today.

        That said, despite the state of the vm module in Node (and its ongoing rewrite which we should watch closely), it should give us exactly what we need: a pure execution environment that has whitelisted access to outside resources. There is some more legwork required today which is where sandbox.js comes in. We haven’t solved all the problems yet (e.g. sandbox isn’t even used today), but cursory trying to break out of the current implementation wasn’t trivial. I plan to get the node security project involved so we get a bit of a better understanding and maybe even a proper security review.

        I hope this addresses all concerns for making this a priority in CouchDB land. I’m looking forward to hack with you.

        [1]: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201309.mbox/%3c222E40F7-99E5-4C2C-8EE1-756F0535263C@apache.org%3e

        Show
        Jan Lehnardt added a comment - Sorry for not addressing security concerns upfront, I knew they would be important and I rushed this ticket instead of taking the time to lay it all out. But first, this is a ticket for a branch for an experiment. This is not a suggestion that we should stop and change everything we do now. If we can’t experiment, we can’t progress, so I’d ask to take this with an experimental state of mind. This ticket is for review and iteration on an idea and some code. This code is an addition to the existing ways of doing things. It is off by default and opt-in and comes with large disclaimers. This view server runtime is not meant to replace couchjs today. It might never replace couchjs. If this is to ever replace couchjs, we need to start somewhere and this is as good a start as any. If there are other starting points, we should capture them in JIRA & branches as well. Getting this into more people’s hands via an experimental feature will allow us to make this good sooner. Dave brought up CORS as a good example of getting something experimental out that we can improve with user feedback once it is out. I hope we can do the same here and I really hope we can use this model a lot more in the future. This project has long suffered from trying to ship perfection. Finally, we already ship an off-by-default and totally dangerous view server that has access to all of CouchDB’s internals and we don’t sweat much about that. Let’s not start now. couchjs works but it is in dire need of improving. Mikeal’s original proposal for make it pipelined is now three or four years old. The fact that one has to juggle slightly scary JavaScript in an unfamiliar environment (SpiderMonkey on the cli is no really common), some scary C and some Erlang to iterate on the query server implementation lead to de-facto zero iteration and improvement. Sure we tacked on a few things and refactored the Erlang side of things, but the fundamental operation of couchjs & main.js has not changed in half a decade. I believe we can open this up to more experimenting and eventually to better software if we have a Node.js version of this. I have outlined the reasons why we want the default query server to be JavaScript in a recent mailing list post [1] so I won’t reiterate this here. What I would love to see here is the following: definition of an acceptable secure code execution environment for view functions. an improved communication method and protocol between the view server and CouchDB. the ripping out of anything that isn’t necessary for views the moving of features like _show/_list/_update etc. to a separate execution environment that is better suited for these kinds of access models. (the way we run _show & _list is really not ideal). and finally and most importantly: other language implementations of the improved protocol and better separated features that we can then promote more prominently. This is a lot of work and we need to ship working software along the way. That’s why I propose to get this experiment going early and start from a point of minimal differences to the current model so we all have a chance of going on the journey of iterating and improving the view server and ultimately a core feature of CouchDB. Now, as for the security scenario in some more detail. I agree with Jason that we need to be very clear about what we mean with various terms and what we compare couchjs-nodejs too, especially because wrecking havoc with couchjs is not too hard today. That said, despite the state of the vm module in Node (and its ongoing rewrite which we should watch closely), it should give us exactly what we need: a pure execution environment that has whitelisted access to outside resources. There is some more legwork required today which is where sandbox.js comes in. We haven’t solved all the problems yet (e.g. sandbox isn’t even used today), but cursory trying to break out of the current implementation wasn’t trivial. I plan to get the node security project involved so we get a bit of a better understanding and maybe even a proper security review. I hope this addresses all concerns for making this a priority in CouchDB land. I’m looking forward to hack with you. [1] : http://mail-archives.apache.org/mod_mbox/couchdb-dev/201309.mbox/%3c222E40F7-99E5-4C2C-8EE1-756F0535263C@apache.org%3e
        Hide
        Johannes J. Schmidt added a comment -

        +1

        Show
        Johannes J. Schmidt added a comment - +1
        Hide
        Jason Smith added a comment -

        Joan Touzet This code does explicitly restrict view code to the same degree as couchjs, so I think we are good there.

        Russell Branca I think we are in agreement about the process of analysis. I am also very sensitive about security. So let's identify all that go into it and I think we will reach the same conclusion.

        First of all, I seriously doubt that the current couchjs "sandbox" is secure. It has not undergone a sustained attack, nor even an audit to my knowledge. So I do not actually want to compare node-couchjs vs. traditional couchjs, I would rather compare node-couchjs vs $something_we_agree_is_acceptable. For example, today, it is trivial to leak state between executions of a map function (just set a global variable). To me, that breaks the idea of a proper sandbox.

        Next, couchjs has libcurl compiled in which can access the filesystem via file:/// URLs. But also, if we are talking about hypothetical exploits, you do not need file i/o compiled into couchjs to do i/o. An (again, hypothetical) shell code attack could make system calls to do i/o.

        This makes me think two thoughts:

        1. We are really talking about the threat from trusted code running, since it can only be created by an administrator in the first place. IMO, the threat is not from malicious attackers but from bugs deployed by the admin. This is why the "global variable" problem of today's couchjs has never been a real-world issue.

        2. Rather than hypothetical threats ("what functionality is compiled in?"; "How many angels can dance?") I would like to focus on practical issues to address. This is definitely marked experimental and I agree it needs improvement before production use. But I'd rather not just say "fasifiability problem" and throw up my hands; I want to make reasoned, rational, real-world assessments about how far we can go with this branch.

        (I would also point out that the falsifiability argument applies to today's couchjs, yet nobody is clamoring to remove it.)

        So for example, whitelisting require() is irrelevant I think. Code in the view server does not have access to the Node.js require function at all. (There is a "require" function however it is the standard couchapp thing, to load code from within a design document: https://github.com/apache/couchdb/blob/master/share/server/util.js#L83-L108)

        Show
        Jason Smith added a comment - Joan Touzet This code does explicitly restrict view code to the same degree as couchjs, so I think we are good there. Russell Branca I think we are in agreement about the process of analysis. I am also very sensitive about security. So let's identify all that go into it and I think we will reach the same conclusion. First of all, I seriously doubt that the current couchjs "sandbox" is secure. It has not undergone a sustained attack, nor even an audit to my knowledge. So I do not actually want to compare node-couchjs vs. traditional couchjs, I would rather compare node-couchjs vs $something_we_agree_is_acceptable. For example, today, it is trivial to leak state between executions of a map function (just set a global variable). To me, that breaks the idea of a proper sandbox. Next, couchjs has libcurl compiled in which can access the filesystem via file:/// URLs. But also, if we are talking about hypothetical exploits, you do not need file i/o compiled into couchjs to do i/o. An (again, hypothetical) shell code attack could make system calls to do i/o. This makes me think two thoughts: 1. We are really talking about the threat from trusted code running, since it can only be created by an administrator in the first place. IMO, the threat is not from malicious attackers but from bugs deployed by the admin. This is why the "global variable" problem of today's couchjs has never been a real-world issue. 2. Rather than hypothetical threats ("what functionality is compiled in?"; "How many angels can dance?") I would like to focus on practical issues to address. This is definitely marked experimental and I agree it needs improvement before production use. But I'd rather not just say "fasifiability problem" and throw up my hands; I want to make reasoned, rational, real-world assessments about how far we can go with this branch. (I would also point out that the falsifiability argument applies to today's couchjs, yet nobody is clamoring to remove it.) So for example, whitelisting require() is irrelevant I think. Code in the view server does not have access to the Node.js require function at all. (There is a "require" function however it is the standard couchapp thing, to load code from within a design document: https://github.com/apache/couchdb/blob/master/share/server/util.js#L83-L108 )
        Hide
        Russell Branca added a comment -

        Jason, this is explicitly a decrease in security given this switches from SpiderMonkey, which does not have File IO compiled in by default at all, to Node.js which has it built in. That is a huge security concern and needs to be treated as such.

        I've thought about the idea of a whitelist to require before, like Klaus and Jan are doing in the new sandbox.js, but the problem I ran into with that approach is that I personally can't prove that there isn't a way to get around that. I'm not saying it can't be done, I'm saying I don't know how to do that.

        It's the falsifiability problem. You can have the most exacting whitelist, but it doesn't mean it's secure.

        This is one of the reasons why I think we should have a node.js execution environment completely isolated from CouchDB as a third party module, and have a simple and secure embedded implementation built in.

        Show
        Russell Branca added a comment - Jason, this is explicitly a decrease in security given this switches from SpiderMonkey, which does not have File IO compiled in by default at all, to Node.js which has it built in. That is a huge security concern and needs to be treated as such. I've thought about the idea of a whitelist to require before, like Klaus and Jan are doing in the new sandbox.js, but the problem I ran into with that approach is that I personally can't prove that there isn't a way to get around that. I'm not saying it can't be done, I'm saying I don't know how to do that. It's the falsifiability problem. You can have the most exacting whitelist, but it doesn't mean it's secure. This is one of the reasons why I think we should have a node.js execution environment completely isolated from CouchDB as a third party module, and have a simple and secure embedded implementation built in.
        Hide
        Joan Touzet added a comment -

        Jason Smith If the sandbox allows access to any additional JS functionality, it does - a view server that fulfills the contract as currently specified does not allow execution of arbitrary code, and is explicitly sandboxed to prevent such things as additional network code, etc.

        I don't know if the mentioned sandbox.js is sufficient to do that, but if it does not explicitly restrict view code to the same degree as couchjs does, it is outside the contract and should not be shipped by this project.

        Show
        Joan Touzet added a comment - Jason Smith If the sandbox allows access to any additional JS functionality, it does - a view server that fulfills the contract as currently specified does not allow execution of arbitrary code, and is explicitly sandboxed to prevent such things as additional network code, etc. I don't know if the mentioned sandbox.js is sufficient to do that, but if it does not explicitly restrict view code to the same degree as couchjs does, it is outside the contract and should not be shipped by this project.
        Hide
        Jason Smith added a comment -

        Russell Branca, can you add some specific details to your objections? I am not sure how to respond to "the security concerns me." What specific security threat do you see? Surely we can agree on an objective definition for evaluating the merit of this branch. I will start that conversation by noting two things: That the existing "sandbox" has no clear definition; and that using a view server requires administrator privileges.

        Joan Touzet regarding "wildly violations the assumed constraints of the viewserver model and provides strictly a view server, not a 'query server'" I am afraid I do not understand at all what that means. "View server" and "query server" are synonyms. I am not aware of any ability to abuse the protocol/provision, or of any coprocessing ability. Is it possible this ticket is confusingly similar to another more ambitious one?

        Show
        Jason Smith added a comment - Russell Branca , can you add some specific details to your objections? I am not sure how to respond to "the security concerns me." What specific security threat do you see? Surely we can agree on an objective definition for evaluating the merit of this branch. I will start that conversation by noting two things: That the existing "sandbox" has no clear definition; and that using a view server requires administrator privileges. Joan Touzet regarding "wildly violations the assumed constraints of the viewserver model and provides strictly a view server, not a 'query server'" I am afraid I do not understand at all what that means. "View server" and "query server" are synonyms. I am not aware of any ability to abuse the protocol/provision, or of any coprocessing ability. Is it possible this ticket is confusingly similar to another more ambitious one?
        Hide
        Joan Touzet added a comment -

        To clarify, it goes beyond security concerns, though those are certainly important. The view server protocol is designed specifically to build and generate views, not to allow streams of information to be arbitrarily processed for non-view-generation concerns.

        I'm perfectly on board with the desire and effort to couple couch server-side to better and bigger things, but we should not be making an explicit statement that abusing the viewserver protocol is the right way of going about that. In its current state that's exactly what this is, and it doesn't belong in the shipping product.

        Show
        Joan Touzet added a comment - To clarify, it goes beyond security concerns, though those are certainly important. The view server protocol is designed specifically to build and generate views, not to allow streams of information to be arbitrarily processed for non-view-generation concerns. I'm perfectly on board with the desire and effort to couple couch server-side to better and bigger things, but we should not be making an explicit statement that abusing the viewserver protocol is the right way of going about that. In its current state that's exactly what this is, and it doesn't belong in the shipping product.
        Hide
        Russell Branca added a comment -

        I'm excited to see progress being made here, but I have to agree with Joan, the security of this concerns me, even with the new sandbox.js you're putting together.

        Show
        Russell Branca added a comment - I'm excited to see progress being made here, but I have to agree with Joan, the security of this concerns me, even with the new sandbox.js you're putting together.
        Hide
        Joan Touzet added a comment -

        I'm -1 on this until such time as it no longer wildly violates the assumed constraints on the viewserver model and provides strictly a view server, not a "query server" or a "JS execution environment." If sandbox.js solves that, then so be it, but I do not want to let users think it's OK to abuse the view server protocol/provision in the server to provide arbitrary coprocessing ability.

        Show
        Joan Touzet added a comment - I'm -1 on this until such time as it no longer wildly violates the assumed constraints on the viewserver model and provides strictly a view server, not a "query server" or a "JS execution environment." If sandbox.js solves that, then so be it, but I do not want to let users think it's OK to abuse the view server protocol/provision in the server to provide arbitrary coprocessing ability.
        Hide
        Dave Cottlehuber added a comment -

        Node's VM module is marked as A couple of links for reference:

        Let's hope that node v0.12 has a robust VM this will be awesome.

        Show
        Dave Cottlehuber added a comment - Node's VM module is marked as A couple of links for reference: node-unstable is currently working on a revamped vm module https://github.com/joyent/node/issues/6208 some risks with the VM module as a whole https://github.com/joyent/node/issues?labels=vm&state=open Let's hope that node v0.12 has a robust VM this will be awesome.
        Hide
        Jan Lehnardt added a comment -

        Just to clear the confusion, the Node.JS query server has the same process semantics as the SpiderMonkey one. Benoit remembered incorrectly that Node’s `vm.runInContext()` forks a new process, which it doesn’t

        Show
        Jan Lehnardt added a comment - Just to clear the confusion, the Node.JS query server has the same process semantics as the SpiderMonkey one. Benoit remembered incorrectly that Node’s `vm.runInContext()` forks a new process, which it doesn’t
        Hide
        Benoit Chesneau added a comment -

        Jan Lehnardtnot totally true since the current patch open external processes as wheel. I am more worried about the way messages are passed and how you can supervise all theses processes.

        I was thinking we could use this ticket as a satellite for others changes, but I'm fine to split the issue anyway.

        Show
        Benoit Chesneau added a comment - Jan Lehnardt not totally true since the current patch open external processes as wheel. I am more worried about the way messages are passed and how you can supervise all theses processes. I was thinking we could use this ticket as a satellite for others changes, but I'm fine to split the issue anyway.
        Hide
        Jan Lehnardt added a comment -

        Benoit Chesneau the process model is the same as with the current couchjs. It has limitations, but works ok for now. Given that there are a few other open items open before this becomes generally useful for people, I’d love to focus on those on this ticket.

        I like the idea of concurrently improving other things as well (that’s why we use branches), but that should happen in other tickets then. I strongly believe limited scope tickets for things like this are the way to go.

        Show
        Jan Lehnardt added a comment - Benoit Chesneau the process model is the same as with the current couchjs. It has limitations, but works ok for now. Given that there are a few other open items open before this becomes generally useful for people, I’d love to focus on those on this ticket. I like the idea of concurrently improving other things as well (that’s why we use branches), but that should happen in other tickets then. I strongly believe limited scope tickets for things like this are the way to go.
        Hide
        Benoit Chesneau added a comment -

        releasing new features is fine. But I would be really cautious on that one, the last thing we want is to break a machine because we used too much ram, cpu or whatever. Which can happen very rapidly on a loaded machine with a lot of view indexations or filtered replications.

        In this case I don't think it's really difficult to go for the model I describe from the current patch anyway this is "just" a matter of having the dispatching done at another level. All what I say is that it may worth to take the time to see if this patch could be improved that way.

        We can iterate in different branches or not. Like I see it there could be 2 works done simultaneously on that patch:

        • check/improve the sandboxing
        • try to improve the multiprocessing model

        At some point we can just decide to ship the current version ("current" as the working version at the time we are looking at it) and continue to iterate on top of it. But I don't see the point of having 2 tickets for the same feature. nothing stop us to keep open a ticket across release until we know the state in the shipped release.

        Show
        Benoit Chesneau added a comment - releasing new features is fine. But I would be really cautious on that one, the last thing we want is to break a machine because we used too much ram, cpu or whatever. Which can happen very rapidly on a loaded machine with a lot of view indexations or filtered replications. In this case I don't think it's really difficult to go for the model I describe from the current patch anyway this is "just" a matter of having the dispatching done at another level. All what I say is that it may worth to take the time to see if this patch could be improved that way. We can iterate in different branches or not. Like I see it there could be 2 works done simultaneously on that patch: check/improve the sandboxing try to improve the multiprocessing model At some point we can just decide to ship the current version ("current" as the working version at the time we are looking at it) and continue to iterate on top of it. But I don't see the point of having 2 tickets for the same feature. nothing stop us to keep open a ticket across release until we know the state in the shipped release.
        Hide
        Jan Lehnardt added a comment -

        Dirkjan Ochtman good call, removed the install instructions from the README and added a pointer to the actual docs.

        Show
        Jan Lehnardt added a comment - Dirkjan Ochtman good call, removed the install instructions from the README and added a pointer to the actual docs.
        Hide
        Dirkjan Ochtman added a comment -

        Looking at the diff, can we make sure README.md only contains developer-targeted stuff? All user-target documentation should ideally be in the actual docs.

        Show
        Dirkjan Ochtman added a comment - Looking at the diff, can we make sure README.md only contains developer-targeted stuff? All user-target documentation should ideally be in the actual docs.
        Hide
        Dave Cottlehuber added a comment -

        +1

        Jan Lehnardt Jason Smith it's great to see this! I think we can ship this feature soon, and in the same way that getting CORS out helped get useful feedback, I think this will do the same.

        Benoit Chesneau your points around efficiency & performance etc are valid, but I'd love to see that discussion & work progressing in a separate ticket. From what I read there's a lot of work reqd before this would be deployable. I'd not want to hold up shipping an experimental feature for vapourware.

        Show
        Dave Cottlehuber added a comment - +1 Jan Lehnardt Jason Smith it's great to see this! I think we can ship this feature soon, and in the same way that getting CORS out helped get useful feedback, I think this will do the same. Benoit Chesneau your points around efficiency & performance etc are valid, but I'd love to see that discussion & work progressing in a separate ticket. From what I read there's a lot of work reqd before this would be deployable. I'd not want to hold up shipping an experimental feature for vapourware.
        Hide
        Jan Lehnardt added a comment -

        @benoit I’d love to evolve the process model and IPC protocol, and I believe that having a node query server runtime will allow us to actually get people working on this.

        But I’d suggest that that is out of scope for this ticket. Let’s land this one and then go improve everything we want to improve.

        The goal of this ticket is to get something that allows us faster iterations and improvements in the future with minimal effort and changes to the overall system today (later changes are more than welcome). I fear if we try to solve everything at once, we’ll never ship anything.

        I think this is a good strategy, hope you agree

        Show
        Jan Lehnardt added a comment - @benoit I’d love to evolve the process model and IPC protocol, and I believe that having a node query server runtime will allow us to actually get people working on this. But I’d suggest that that is out of scope for this ticket. Let’s land this one and then go improve everything we want to improve. The goal of this ticket is to get something that allows us faster iterations and improvements in the future with minimal effort and changes to the overall system today (later changes are more than welcome). I fear if we try to solve everything at once, we’ll never ship anything. I think this is a good strategy, hope you agree
        Hide
        Noah Slater added a comment -

        Excellent work. Looking forward to seeing this land.

        Show
        Noah Slater added a comment - Excellent work. Looking forward to seeing this land.
        Hide
        Benoit Chesneau added a comment - - edited

        I am not a fan of the multi-process design in this patch. It can be costly when passing messages. I would rather borrow some principles of the chromium design [1]. Ie having direct channels (as pipes, unix sockets, mmaps, whatever) between the erlang vm and each contexts, instead of routing it at the JS level. Replace tabs by ddocs and we could have a similar design anyway.

        Thoughts?

        [1] http://www.chromium.org/developers/design-documents/multi-process-architecture

        Show
        Benoit Chesneau added a comment - - edited I am not a fan of the multi-process design in this patch. It can be costly when passing messages. I would rather borrow some principles of the chromium design [1] . Ie having direct channels (as pipes, unix sockets, mmaps, whatever) between the erlang vm and each contexts, instead of routing it at the JS level. Replace tabs by ddocs and we could have a similar design anyway. Thoughts? [1] http://www.chromium.org/developers/design-documents/multi-process-architecture
        Hide
        Jason Smith added a comment -

        A note on terminology (at least to my understanding).

        My work is not a "query server" but rather (I guess) a "JavaScript environment". All it does is run some JavaScript code and provide a few globals like readline(), print(), and a few others.

        The "query server" is the stuff in share/server/*.js, which is compiled into one big main.js during building. My project runs the query server verbatim, and so it is a drop-in replacement for couchjs except using v8 instead of SpiderMonkey. (That is not very interesting for users, it feels 100% the same. What is interesting is that it is easier to install.)

        Show
        Jason Smith added a comment - A note on terminology (at least to my understanding). My work is not a "query server" but rather (I guess) a "JavaScript environment". All it does is run some JavaScript code and provide a few globals like readline(), print(), and a few others. The "query server" is the stuff in share/server/*.js, which is compiled into one big main.js during building. My project runs the query server verbatim, and so it is a drop-in replacement for couchjs except using v8 instead of SpiderMonkey. (That is not very interesting for users, it feels 100% the same. What is interesting is that it is easier to install.)
        Show
        Jan Lehnardt added a comment - - edited ASF git repo here: https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=1894-feature-experimental-nodejs-couchjs GitHub compare view here: https://github.com/janl/couchdb/compare/apache:master...1894-feature-experimental-nodejs-couchjs

          People

          • Assignee:
            Unassigned
            Reporter:
            Jan Lehnardt
          • Votes:
            2 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development