On Jan 31, 2013, at 16:20 , Robert Newson <[email protected]> wrote:
> Part of the difficulty in asserting the correctness of the sandbox is > that important tests like "cannot read file", "cannot write file", > "cannot open socket" cannot be written against SpiderMonkey (or, > presumably, V8) as they simply don't provide those features. Node > does, and that's the principal advantage of it over V8 as I understand > things, but it is obviously silly to write a test suite on that basis. Excellent point. What ways of mitigating to we have? Can we construct a sandbox that only allows calling of functions that we specify (has Jason done this?). Best Jan -- > > B. > > On 31 January 2013 15:17, Jan Lehnardt <[email protected]> wrote: >> >> On Jan 31, 2013, at 15:52 , Benoit Chesneau <[email protected]> wrote: >> >>> On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith <[email protected]> wrote: >>> >>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <[email protected] >>>>> wrote: >>>> >>>>> >>>>> That whole process sounds like not a lot of fun. >>>>> >>>> >>>> Right. That is kind of my point. CouchDB is a JavaScript thing, and >>>> nowadays people have a very well-adopted and well-understood JavaScript >>>> engine on their computers. Maybe it should just use that. >>>> >>>> >>>> >>> couchdb is not a javascript thing, This is a database in which one and the >>> default engine for M/R is using the language javascript. >>> >>> Not all developers have nodejs installed. None of my servers have it. >> >> The question is not if you server have it, but whether you could install a >> compatible version easily. >> >> I’d love to hear if you or others are not covered by >> >> https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager >> >> >>> A,d >>> I'm not alone in that case. Imo we don't take the problem at the right >>> angle. Note that I'm fine to have eventually a nodejs view server around >>> if it's needed, that not the question. >>> >>> Which problems are we trying to solve ? >>> >>> - problem with the spidermonkey distribution. There are many versions >>> deployed on different OS/distributions. Even some that aren't packaged by >>> mozilla >>> - having more concurrency for couchapps and view indexation >> >> I’d say this is irrelephant to the view engine. The idea here is that a >> Node view engine is much more likely to see progress towards that goal >> though as it comes with an enthusiastic community that shares the interest >> of having an awesome CouchDB Server (via NPM). NPM is effectively a CouchApp >> >> >>> I would add a third one: beeing able to distribute couchdb with a view >>> engine that work on mobile platform or that eases the distribution on the >>> mobile. But this isn't the main problem and not the one we are all trying >>> to solve if I understood well. >> >> Not a bad point, but also out of scope for this discussion, I’d say. Either >> way, bot engines have been ported (SM) or designed (V8) to also run on >> mobile. >> That doesn’t mean all is equal, but the basics for this are there. >> >> >>> Imo one of these problems can be solved by improving the view protocole. I >>> think we could work on a new protocole. And while we are here really >>> document the current one as a specification in text. >> >> We have seen zero evolution of the view protocol in the past. My hope is >> that with a wider target audience (node folks), we’ll finally get >> contributions there. >> >> >>> The second, need some discussions. I'm with randall, I think that porting >>> couchjs to v8 is not that hard and would really solve the problem. None of >>> the distributions have the same of nodejs also there is still the >>> sandboxing to fix. And it seems really weird to remove I/O on nodejs. >>> Things that make the difference between nodejs and v8. Having commonjs is >>> another thing. One advantage of v8 vs spidermonkey is that we can embed it >>> in our code. the license allows. Also building v8 is a way easier compared >>> to spidermonkey. >>> >>> If we are all agree on these two problem let's try to do some action on >>> them and first we shoudl collect all the current feature we have and that >>> we don't want to lost, then start to find solution to handle them and fix >>> the issues we have. >>> >>> Thoughts? >> >> I really like the idea of throwing away all that C code (and gain JS code >> instead). >> >> And I like that Jason did demonstrate that it is feasible. >> >> Two things remain: >> >> 1. Show that sandboxing is sufficient for our needs >> - can we come up with JS code that is supposed to fail and then make sure >> it does? >> >> 2. Show that the Node view server works on commonly distributed Node >> versions. >> - if, say Node 0.6 is widely supported on the Latest-1 Ubuntu release >> (just for the >> sake of argument) we should make sure it is compatible. >> - Can you all help collecting the minimally available Node versions for >> systems that >> we intend to support with master? >> >> Cheers >> Jan >> -- >>
