couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 16:08:25 GMT
On Thu, Jan 31, 2013 at 4:43 PM, Jan Lehnardt <jan@apache.org> wrote:

>
> On Jan 31, 2013, at 16:37 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>
> > On Thu, Jan 31, 2013 at 4:17 PM, Jan Lehnardt <jan@apache.org> wrote:
> >
> >>
> >> On Jan 31, 2013, at 15:52 , Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> >>
> >>> On Thu, Jan 31, 2013 at 2:23 PM, Jason Smith <jhs@iriscouch.com>
> wrote:
> >>>
> >>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <
> >> paul.joseph.davis@gmail.com
> >>>>> 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
> >>
> >>
> >>
> > Well this is the question somehow. Today when I release rcouch or
> modified
> > bigcouch releases I can build them statically. I then only distribute the
> > release without any other dependencies than the system and without
> > requiring more rights than a user have most of the time. If not I have to
> > make sure I have the correct nodejs etc.
>
> Why can’t you bundle Node in rcouch?
>


Was thinking about it, there is nothing that prevent it i guess, but the
toolchain needed is quite more expensive. We need either python or cmake to
build nodejs today if I remember, so it imply more tooling. Just a matter
of organising stuff. This for desktop. It is also a lot more complicated
than just integrating v8.


On IOS and Android there isn't any stable release of nodejs today which can
be problematic. It is easier with v8 now but this is another topic.


>
> > Also the point is that nodejs isn't so widely deployed or already
> insyaled
> > that some say.
>
> Yes, I get that. But I contest that premise. The only thing that matters
> is whether Node is *available* on these systems.
>

Well not really. Some users have specific requirements for dependencies.
For example lot of centos/rhel users can't install anything coming outside
legal repos. Anyway useful link. (I was just thinking that if we jump into
node or v8 we can provide q tool discovering such resource for the user on
install, a `check-dependencies`script) .



>
> * * *
>
> I’d like to agree with everyone on the minimal requirements that
> technically
> need to be vetted before we can make a switch. Then see if we can reach
> that,
> and if we do, agree to switch. If we can’t agree on the first thing, all
> this discussion is moot. Part of the minimal requirements can be "make sure
> that in a later step we can still do X (like embedding or bundling the JS
> env)",
> but I don’t think we have to have definite answers for these things today,
> as long as we don’t block them.
>


My requirements  for a first try are:

- sandboxing: no I/O accepted by default, no global variables, or functions
that leak content
- embed in our source code so we don't rely to external for that. and don't
ask to the user to check outside



> Cheers
> Jan
> --
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message